ITK/DICOM

DICOM: Rescale Slope/Intercept

Another question that is often asked on insight-users is : I am trying to read/write a DICOM image, but the pixel data has changed (the scalar range has changed from input file).

This surely comes from the fact that you did not used the proper PixelType to instanciate your reader. You have to consider :

• Bits Allocated
• Bits Stored
• Pixel Representation
• Samples per Pixel

AND:

• Rescale Intercept
• Rescale Slope

For instance you can use the DicomImageReadPrintTags example in ITK/IO, or even better gdcminfo

$ DicomImageReadPrintTags image.dcm | grep "Slope\|Intercept\|Bits\|Pixel Rep"
(0028|0100) Bits Allocated = 16
(0028|0101) Bits Stored = 12
(0028|0103) Pixel Representation = 0
(0028|1052) Rescale Intercept = -1000
(0028|1053) Rescale Slope = 1

In this case when you look only at how the pixel are stored on disk: Bits Allocated, Bits Stored and Pixel Representation, you clearly see that they are stored as unsigned short. However looking now at how the pixel are mapped to real world value you need to apply an afine transform:

 RWV = slope * SP + intercept

In which case you'll get signed value. Therefore you will need a signed short pixel to display the pixel value.

One might ask, how can I be sure that signed short will be enough for loading the stored pixel value ? You have two clues: either look at pixel stored: 12bits, therefore you know that signed short will be enough. Or you can have a look sometimes at Smallest Image Pixel Value / Largest Image Pixel Value. It will tell you what are the min/max in your stored image:

$ DicomImageReadPrintTags image.dcm | grep "Image Pixel Value"
(0028|0106) Smallest Image Pixel Value = 0
(0028|0107) Largest Image Pixel Value = 4095