Question

I’m generating a synthetic DICOM image with the Insight Toolkit (using itk::GDCMImageIO) and I’ve found two problems:

1. VolView fails loading my DICOM (with the message: Sorry, the file cannot be read). ITK-Snap opens and shows it OK.
2. I’m trying to use this image in a Stryker surgical navigator. The problem is that the image is loaded ok, but then the padding pixels are shown in a certain gray level, showing a box (actually the bounding box) of the image. If I load non synthetic DICOMs this doesn’t happen.

This is what gdcminfo is showing:

MediaStorage is 1.2.840.10008.5.1.4.1.1.7 [Secondary Capture Image Storage]
TransferSyntax is 1.2.840.10008.1.2.1 [Explicit VR Little Endian]
NumberOfDimensions: 2
Dimensions: (33,159,1)
Origin: (0,0,0)
Spacing: (1,1,1)
DirectionCosines: (1,0,0,0,1,0)
Rescale Intercept/Slope: (0,1)
SamplesPerPixel    :1
BitsAllocated      :16
BitsStored         :16
HighBit            :15
PixelRepresentation:0
ScalarType found   :UINT16
PhotometricInterpretation: MONOCHROME2 
PlanarConfiguration: 0
TransferSyntax: 1.2.840.10008.1.2.1
Orientation Label: AXIAL

I’m using unsigned short as pixel type in itk::Image object and I’m setting all the padding pixels to 0 (zero), as is suggested by the DICOM standard for unsigned scalar images. gdcminfo does not show it, but I’m also setting the Pixel Padding (0028,0120) field to zero.

I would really appreciate any hint about this problem.

Thanks in advance,

Federico

Answer 1

After a lot of experimentation, I’ll answer my own question. I’ve found that some DICOM readers directly assume that you’re using the Hounsfield scale if the type of the DICOM files is CT. In this case you have to use short as pixel type and use -1024 for air (less than -1000 is air in Hounsfield scale), and it will render the image ok. These readers I’ve been experimenting with don’t use the Pixel Padding field nor the Rescale Intercept/Slope. But If you use ITK-Snap/VolView/3DSlicer you won’t have any problem if you specify those fields.