[Insight-users] DICOM import doesn't work properly

[Raphael Hoever]

Hi Mathieu,
thanks for your help. You were right, the intercept is -1024 (seems to 
be usual) so I need to import it as a signed short and then shift it by 
1024 to be able to store it as a 16 bit tif. Now it works perfectly. 
Again, thank you very much. I didn't know anything about intercept and 
slope so far.
Bye,
Raphael


Mathieu Malaterre wrote:
> Raphael,
>
>     Could you post the output of DicomReadPrintTags so that I can have 
> a look at it. Pay particular attention to the intercept and rescale 
> slope that need to be applied to the stored pixel (therefore your 
> final pixel type could be different than the stored one).
>
>     If you cannot see anything wrong in the output, please send me a 
> copy of one slice of your series.
>
> Thanks
> Mathieu
>
> Raphael Hoever wrote:
>> Hi,
>> I am trying to import DICOM images with ITK. I tested 
>> itk::DICOMImageIO2, itk::DicomImageIO and itk::GDCMImageIO for the 
>> import interface but no matter what I do the pixel values of the 
>> images are shifted by a very large number (64,512 = 11111100 
>> 00000000) and since the InputPixelType is unsigned short (the DICOM 
>> images allocated 16 bit per pixel and use the lower 12 bit for the 
>> data) I observe overflows at high intensity values. So for instance 
>> if the original pixel intensity is 4095 the pixel value in the output 
>> image is (4095 + 64512)mod216 = 3071.
>>
>> I am using ITK 2.6 and the DICOM images are from a Siemens Sensation 
>> 64 scanner.
>> Here is my code for reading just one DICOM image (the result is the 
>> same if I read the whole sequence) and exporting it as a 16 bit tif 
>> image (also unsigned char, so the cast filter is not mandatory):
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hoever.vcf
Type: text/x-vcard
Size: 354 bytes
Desc: not available
Url : http://public.kitware.com/pipermail/insight-users/attachments/20060511/81ff1d36/hoever.vcf