[Insight-users] Signed vs. Unsigned Pixels in DICOM file?

[Bill Lorensen]

Jaety,

The CT 9800 is a really old GE scanner. I believe it existed before DICOM.
Sounds like this is a client problem.

Bill


On 3/12/07, Jaety Edwards <jaety at cs.berkeley.edu> wrote:
>
> Hello All,
> I've been trying to debug a problem with ITK loading certain DICOM
> images, and I've finally realized that the problem is in the header of
> the DICOM image itself. The header has the following fields
>
> PixelRepresentation = 1
> BitsAllocated = 16
> BitsStored = 12
> HighBit = 11
>
> This should mean that the pixel are signed, and 12 bits long. However,
> in reality the pixels are unsigned. Since ITK/gdcm is (correctly
> according to the header) treating these pixels as signed, the highest
> values are getting flipped to be negative.
>
> This is not a bug in a single file. I've seen it in a number of files
> I've received. What I'm trying to figure out is how I can reliably
> catch this problem in DICOM files I'm sent.
>
> The header tells me (DerivationDescription) that the image is 'From GE
> CT 9800 by DICOMatic 1.5 rev-1d'. Online, I've seen some references
> indicating that this signed/unsigned confusion is a known problem with
> some dicom files (e.g. http://tinyurl.com/3afz55), but I haven't been
> able to get any details. Is it a known problem in all files coming
> from a GE CT 9800? Is it probably a problem with the DICOMatic
> software the client used to convert it?
>
> Other headers that might be clues:
> PixelPaddingValue = -32768
> RescaleIntercept = -1000
>
> Any suggestions greatly appreciated.
> Thanks,
> Jaety
> _______________________________________________
> Insight-users mailing list
> Insight-users at itk.org
> http://www.itk.org/mailman/listinfo/insight-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://public.kitware.com/pipermail/insight-users/attachments/20070312/bb20b8ea/attachment.html