[Insight-users] Problem with pixel representation type
Luis Ibanez
luis.ibanez at kitware.com
Mon, 12 Jan 2004 11:23:11 -0500
Hi Soumen,
It seems that your CT is using hounsfield
units, where you have equivalences like
Tissue CT Number (HU)
Bone = 1000
Liver = 40-60
White Matter = 46
Gray Matter = 43
Blood = 40
Muscle = 10-40
Kidney = 30
CSF = 15
Water = 0
Fat = -50 to -100
Air = -1000
About the inconsistency in the DICOM headers
of your images, I'm afraid that you will have
to address this question to your image supplier :-)
The range for PET looks very suspicious.
I would strongly suggest you to use one of two
following applicatioons trying to read and
visualize your images.
A) MRIConvert
http://lcni.uoregon.edu/~jolinda/MRIConvert
B) VolView
http://www.kitware.com/products/volview.html
You can get both of them for free, and use
them to check numeric values on the image
pixels, as well as saving your images in
a different file format.
Once you establish the validity of the images
you may start processing them with ITK.
Regards,
Luis
----------------------------------------
soumend at magnum.barc.ernet.in wrote:
> Hi!!!!
> Thnx for ur help.
>
> I have used the minimummaximumimagecalculator for 2 sets of CT and 2 sets of
> PET images.The values I got are as follows......
>
> 1st CT 3071.0 & -1024.0
> 2nd CT 585.0 & -1024.0
>
> 1st PET 32760.0 & -32767.0
> 2nd PET 22035.0 & 0.0
>
> Now my questiion was why do the CT images have signed value though the pixel
> representation field in their header shows(value =0) that these shoud have
> unsigned value?
>
> As far as the code is concerened , the itkDICOMParser and itkApphelper was not
> working properly with PET images so I had to write seperate classes to read
> both CT and PET images and a filet to export the image data from itk to vtk (
> the filter does not differ much from the existing one).
>
> soumen
>
> Quoting Luis Ibanez <luis.ibanez at kitware.com>:
>
>
>>Hi Soumend,
>>
>>
>>1) ITK image readers perform casting when reading
>> the images. If you declare the reader as:
>>
>> typedef signed char PixelType;
>> typedef itk::Image< PixelType, 3 > ImageType;
>> typedef itk::ImageFileReader< ImageType > ReaderType;
>>
>> ReaderType::Pointer reader = ReaderType::New();
>>
>> reader->SetFileName("inputfile.dcm");
>>
>> The "reader" will take the pixel type of the file
>> and cast it to "PixelType". If image file has an
>> image of pixel type = unsigned char and it gets
>> displayed correctly using "unsigned char", it is
>> likely that the image is not using the entire
>> intensity range [-128:127].
>>
>> The simple way to know is for you to instantiate
>> and ImageFileReader of pixel type = "unsigned char"
>> read the image and use the MaximumMinimumCalculator
>> in order to compute the maximum and minium values of
>> the image.
>>
>> Once you get this two (min/max) numbers,
>> please let us know.
>>
>>
>>2) This relates to (1).
>> You may want to read carefully the IO chapter of
>> the SoftwareGuide
>>
>> http://www.itk.org/ItkSoftwareGuide.pdf
>>
>> Chapter 7, pdf-page 219.
>>
>>
>> Note that if what you are trying to do is to
>> create a "Generic" image viewer, you should
>> prepare multiple instantiations of the ITK
>> pipeline. You may find examples on how to do
>> this on the VolView Plugins code in
>>
>> InsightApplications/VolviewPlugins
>>
>> Otherwise, your reader/viewer has been working
>> fine just because you have been lucky so far
>> with your data. Murphy's laws clearly state that
>> you will run out of luck the day you demo this
>> application to your supervisor or your most
>> important client.
>>
>>
>>3) You can easily renormalize the image intensity
>> values before display on your VTK visualization
>> pipeline. You will have to post the code of your
>> visualization pipeline if you want to get advice
>> on this regard.
>>
>>
>>4) Resolution (image pixel spacing) is irrelevant
>> in this context.
>>
>>
>>
>>Regards,
>>
>>
>> Luis
>>
>>
>>
>>-----------------------------------
>>soumend at magnum.barc.ernet.in wrote:
>>
>>>HI !!!!!
>>>
>>>I have developed a dicom image viewer which will read the dicom image using
>>
>>>ITK and displayed through VTK. Still I have some dought in this regard.will
>>
>>>anybody help me out?
>>>
>>>i) Though the pixel representation field of CT image shows 0 (i.e unsigned
>>
>>>char),the image is properly displayed when pixel type is taken as signed
>>
>>char.
>>
>>>Whereas PET image has pixel representation 1 behaves good with signed char
>>
>>>pixel type as it should be. Why the discrepency is there for CT image?
>>>
>>>ii) In the DICOMApphelper the pixel is read as unsigned char for CT image
>>
>>and
>>
>>>as float in the case of PET image (due to rescale slope and offset values).
>>
>>>But in my program i have defined the pixel type of input image as signed
>>>char. My question ....though the pixel values are read differently still
>>>images get displayed doesnt matter what is the input pixel type. Why is it
>>
>>so?
>>
>>>iii) the range of pixel value is different for CT and Pet images ...now to
>>
>>>read from a single interface how can i set the pixel range dynamically in
>>
>>the
>>
>>>look up table(it is VTK related qs ..still)?
>>>(resaolution of CT images are much better than PET images)
>>>
>>>
>>>
>>>-------------------------------------------------
>>>
>>>_______________________________________________
>>>Insight-users mailing list
>>>Insight-users at itk.org
>>>http://www.itk.org/mailman/listinfo/insight-users
>>>
>>
>>
>>
>
>
>
>
> -------------------------------------------------
>
>