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

[Jaety Edwards]

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