[Insight-users] Re: More Qs about DICOM image
Mathieu Malaterre
mathieu.malaterre at kitware.com
Thu Apr 28 13:43:15 EDT 2005
Laurent,
Could you send us the output of ImageInformation it's an example in ITK
that dump information of a DICOM image (or PrintFile if you use the full
gdcm lib). My guess is that there is a problem when readin gth
Photometric Interpretation. Depending if this is MONOCHROME1 or
MONOCHROME2 the white/black are coded differently.
I'll double check with gdcm team if gdcm 1.0 handle this properly.
Mathieu
laurent.paul at club-internet.fr wrote:
> Hi luis, Hi all,
>
> Sorry to dig up this message but it contains a piece of answer to my problem.
>
> I want to read a dicom serie to convert it to a volume.
> so far, i used a soft which do that, i tried too the MRIconvert which is a good converting tool. but it's not a good solution to use multiple softwares for one goal
> Plus, my goal is to create a "software" (in the future) which will register, threshold.... and do some other things. For instance, I build several *.exe to achieve my goal. So I use ITK and DicomSeriesReadImageWrite2.cxx (for example) to read the serie.
>
> Dicom images are CT with an intercept value (-1000) ans slope (1). The range of images is [0 3000]. So, when I convert images into volume, it maps pixel's value to [-1000 2000]. When I visualize the volume with a certain software (MRicro which takes care of intercept value but doesn't make any difference between signed and unsigned]), the image is inverted. I mean black is white and white is black (it looks like a song!?). If I open with the "open raw" function of Volview, I can specify if datas are signed
> or unsigned ints, the volume looks good.
>
> I don't understand how the reader acts. I look at the hexadecimal value in the dicom file and in the resulting volume. In Dicom, the black is 0x0000. In Analyze, that's 0x18FC. I'm wondering how the convertion is made because data type is unsigned int, and the black value in my volume is -1000. How does it work?
>
> Second question:
> Is that could be a problem to handle the data, crop the volume, register volumes... ?
>
> Thanks a lot,
>
> Laurent.
>
>
>
>>Hi Soumen
>>
>>When you use the ITK DICOM reader you
>>don't have to worry about the values
>>
>> RESCALE_SLOPE
>> RESCALE_OFFSET
>>
>>There is nothing you have to do about
>>this values. The reading process in
>>DICOMAppHelper.cxx is using these factor
>>for scaling the pixel values read from
>>the DICOM file.
>>
>>You can look at this code in
>>
>> Insight/Utilities/DICOMParser/
>> DICOMAppHelper.cxx
>>
>> in the method PixelDataCallback()
>> on lines 950 - 1082
>>
>>
>>All this was just the explanation for why
>>the DICOM header says that the pixels are
>>encoded in 'unsigned ints' and you still
>>get negative values when the image is read.
>>
>>The pixel values stored in the files are
>>indexes to the LUT. The pixel values read
>>by ITK into memory are the result of applying
>>the LUT mapping so they are not indexes anymore.
>>
>>Now that you understand why this is so, you
>>can forget about this fact and simply read
>>the images into memory.
>>
>>
>
> <-----
>
>>
>>As far as you are concerned for the registration
>>process you should declare your images as follow
>>
>>
>>typedef itk::Image< signed short, 3 > CTImageType;
>>typedef itk::Image< float, 3 > PETImageType;
>>
>>Then you declare readers:
>>
>>typedef itk::ImageSeriesFileReader< CTImageType > CTReaderType;
>>typedef itk::ImageSeriesFileReader< PETImageType > PETReaderType;
>>
>>and read both DICOM images into memory.
>>
>>Since this is multi-modality registration
>>your options for image metrics are 3
>>
>> - MutualInformation (Viola-Wells)
>> - MattesMutualInformation
>> - MutualInformatioinHistogram
>>
>>For all of them the first step of the registration
>>process involves to *normalize* the images in such
>>a way that they have mean=0 and sigma= 1.
>>So, all your concerns regarding the range of intensities
>>are solved after you perform this normalization.
>>
>>The normalization is computed by the filter
>>itkNormalizeImageFilter
>>http://www.itk.org/Insight/Doxygen/html/classitk_1_1NormalizeImageFilter.html
>>
>>It is convenient to declare the output image type of
>>this filter as having pixelType = float.
>>
>>
>>Please read the section on Multi-Modality registration
>>on the Software Guide
>>
>> http://www.itk.org/ItkSoftwareGuide.pdf
>>
>>
>>Section 8.4, pdf-pages 255 - 263.
>>
>>Regards,
>>
>> Luis
>>
>>-----------------------------------------
>>soumend at magnum.barc.ernet.in wrote:
>>
>>Hi!!!!
>>Thnx again for ur help.
>>
>>Actually I have two sets of images. One CT and other one is a set of PET
>>images.
>>
>>The characteristics of the Two sets are as follows....
>>
>>CT images...
>>
>>origin-> -140.24,-301.24,634.00
>>Spacing-> 0.525391,0.525391,5
>>rescale slope-> 1.0 (first slice,infact it is the same for all slices in my
>>case)
>>rescale offset-> -1024
>>Dimension->512 X 512
>>No. of. Slices->116
>>
>>Pet Images....
>>
>>origin-> -270.5,-270.5,688.50
>>Spacing-> 4.226563,4.226563,4.25
>>rescale slope->2.94343 (for first slice but different for other slices)
>>rescale offset-> 0
>>Dimension-> 128 X 128
>>No. of. Slices-> 163
>>
>>(While reading the series I read the offset value from the first slice only
>>though the slope values are read from every slices. Is it correct to assume
>>that the offset remain same for all the slices ?)
>>
>>Now plz tell me how to proceed with the registration?
>>
>>And another thing I want to ask.....in case images use LUT....then what i am
>>getting from the file is the index to the table(?)...then how to get the
>>actual intensity value?
>>
>>Thanking u again and expecting ur help...
>>soumen
>>
>>
>>Quoting Luis Ibanez <luis.ibanez at kitware.com>:
>>
>>
>>
>>>Hi Soumen,
>>>
>>>
>>>1) Is likely that your CT image is using a Look Up Table (LUT).
>>>
>>> In that circumstance, the pixels values correspond to
>>> indexes to entries in the LUT and therefore can be unsigned
>>> ints. The real hounsfield units of the image are the values
>>> translated by the LUT and are only recovered when you read
>>> the image.
>>>
>>> Please look at the DICOM standard at
>>>
>>> http://medical.nema.org/dicom/2003.html
>>>
>>> in particular to
>>>
>>> http://medical.nema.org/dicom/2003/03_03PU.PDF
>>>
>>> Section A.1.2.9 MODALITY LUT IE, pdf-page 62.
>>>
>>> In your DICOM header you can check the tag entries
>>>
>>> RESCALE_SLOPE (0028,1052)
>>> RESCALE_INTERCEPT (0028,1053)
>>>
>>>
>>>
>>>2) About the PET image,
>>> It not clear what you mean by the image being
>>>
>>> "not quite prominent"
>>>
>>> Note that "image quality" is a very ambiguous
>>> and therefore dangerous term. An image is an
>>> information carrier, the fact that the image
>>> may look nice to the human eye is just a
>>> secondary factor.
>>>
>>> The question you should probably ask is:
>>>
>>> How to extract the appropriate information
>>> from the PET image ?
>>>
>>> You are probably trying to locate a tumor or
>>> track its evolution over time. In this context
>>> you need to keep in mind the physics behind the
>>> image acquisition process.
>>>
>>>
>>>
>>>3) In order to register images two with different
>>> image spacing you must do two things:
>>>
>>>
>>> A) Check seven times that the values of origin
>>> and pixels spacing are correctly specified
>>> in millimeters in both images. Once you have
>>> check that seven times, you go for a walk and
>>> when you come back, check the values for an
>>> eighth time.
>>>
>>>
>>> B) Read the chapter on image resampling from
>>> the SoftwareGuide.
>>>
>>> http://www.itk.org/ItkSoftwareGuide.pdf
>>>
>>> Section 6.7.1, pdf-page 199.
>>>
>>> Make sure that you run by yourself all the
>>> examples in
>>>
>>> Insight/Examples/Filtering
>>> ResampleImageFilter.cxx
>>> ResampleImageFilter2.cxx
>>> ResampleImageFilter3.cxx
>>>
>>> Make sure that you understand and can
>>> interpret correctly the output of these
>>> examples. The main factor to understand
>>> is that image registration is performed
>>> in physical coordinates and not in pixels.
>>> You have to think in millimeters and
>>> degrees.
>>>
>>>
>>>
>>>
>>>
>>>Regards,
>>>
>>>
>>>
>>> Luis
>>>
>>>
>>>------------------------------------
>>>soumend at magnum.barc.ernet.in wrote:
>>>
>>>
>>>
>>>>HI!!!!
>>>>Thnx for the reply.
>>>>
>>>>I have used the minimummaximumimagecalculator to find the pixel value range
>>>
>>>in
>>>
>>>
>>>>the images. And i found that for CT image it is about -1000 to +1200 and
>>>
>>>for
>>>
>>>
>>>>PET images it is very large 0 to 22000(or even 32767 for one set). But muy
>>>
>>>qs
>>>
>>>
>>>>is though the pixel representation field in CT image header shows the value
>>>
>>>0
>>>
>>>
>>>>i.e unsigned value, still it has signed pixel value ...why it is so?
>>>>
>>>>I also want to ask few more things.....
>>>>1. PET iamges are of very low resolution but has very high intensity
>>>>range.....is that the reason that PET images not quite prominent. If yes
>>>
>>>then
>>>
>>>
>>>>how to improve the image quality?
>>>>
>>>>2. To register two images having diff slice thickness,diff spatial
>>>
>>>resolution
>>>
>>>
>>>>what are the initial things I have to do to make the images ready to
>>>
>>>register?
>>>
>>>
>>>>Thnx for the reply....soumen
>
>
> _______________________________________________
> Insight-users mailing list
> Insight-users at itk.org
> http://www.itk.org/mailman/listinfo/insight-users
>
More information about the Insight-users
mailing list