Rescale Slope/Intercept

A question that is often asked 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 pixel type to instanciate your reader. You have to consider:

  • Bits Allocated

  • Bits Stored

  • Pixel Representation

  • Samples per Pixel


  • Rescale Intercept

  • Rescale Slope

For instance you can use the DicomImageReadPrintTags example in the ITK Software Guide, or even 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 affine transform:

\[RWV = slope * SP + intercept\]

where \(RWV\) is the real world value, and \(SP\) means Samples per Pixel.

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

Why did the header of my DICOM file change?

A common question that frequently arises after using itk::GDCMImageIO to read, update and write out a DICOM file is: why did my header file change during the update mechanism?

DICOM has a specific section on what a DERIVED image is (PS 3.3-2008, C. Image Type):

If the pixel data of the derived Image is different from the pixel data of the source images and this difference is expected to affect professional interpretation of the image, the Derived Image shall have a UID different than all the source images.

Further, in the definition of Derivation Description there is a note which says (PS 3.3-2008, C. Derivation Description):

Examples of Derived Images which would normally be expected to affect professional interpretation and would thus have a new UID include:

  1. Examples of Derived Images that would normally be expected to affect professional interpretation and would thus have a new UID include:

    a. images resulting from image processing of another image (e.g. unsharp masking),

    b. a multiplanar reformatted CT image,

    c. a DSA image derived by subtracting pixel values of one image from another,

    d. an image that has been decompressed after having been compressed with a lossy compression algorithm. To ensure that the user has the necessary information about the lossy compression, the approximate compression ratio may be included in Derivation Description (0008,2111).

An example of a Derived Image that would normally not be expected to affect professional interpretation and thus would not require a new UID is an image that has been padded with additional rows and columns for more display purposes.

At a minimum you should expect the minimal set of changes:

  • Assign a new SOP Instance UID.

  • Reference the SOP Instance UID of the original in Source Image Sequence.

  • Set the Image Type value 1 to DERIVED rather than ORIGINAL

The identical SOP Instance UID of two files mean that both files are representations of the same objects and thus have identical content. It is however allowed that both files uses different transfer syntax uid (i.e. they have a different binary representation on disk) (implicit/explicit, little/big endian). When a DICOM file is sent to a PACS, it is up to the implementor to decide what to do in case of duplicate SOP Instance UID. In most case you should expect that the image is not resent, as standard garantee this is already the same object.

⚠️ Warning

Adding an overlay is considered to affect professional interpretation of the images. Thus new UIDs are required !