where U is in output units, m is the rescale slope, SV is the stored value, and b is the rescale intercept. Other tags describe the stored value format further, such as Bits Allocated (0028|0100), Bits Stored (0028|0101), Pixel Representation (0028|0103), and Sample per Pixel (0028,0002).

Why have a different representation on disk versus in memory? A different range of values may be possible with the representation stored on disk versus in memory. An example: CT images, whose pixel values are measured in Hounsfield units, which can have negative values, are commonly stored with an unsigned integer. As a consequence, it is common for CT DICOM files to have a negative intercept. The linear scaling is also applied in cases where a pixel may have a large range of values while storing the values with as few bits as possible and while avoiding quantization errors. This is commonly applied in PET imaging where the range of activity values measured may exceed small integers. Also, the maximum PET activity may vary greatly from slice to slice; for example, a slice with a tumor may have very high values relative to a healthy tissue slice. For this reason, the rescale intercept / slope values often vary on a slice-by-slice basis for a PET image series.

How is Rescale Intercept / Slope Handled in ITK?

In ITK, the desired itk::Image pixel type is expressed as a template argument to the itk::ImageFileReader. Internally, itk::ImageFileReader uses an itk::ImageIOBase class to read the given file, which has a specific format. Usually, the file is read with the same representation as stored on disc, then it is cast to the desired itk::Image pixel type.

For DICOM files read with the GDCMImageIO, the pixel types are first read from their representation stored on disc, the InternalComponentType, and then the rescale intercept and rescale slope are applied.

How do I write a DICOM file with ITK that has a non-identity Rescale Intercept / Slope?

An important bug when writing DICOM files was fixed in ITK with the release of 4.6.0. The rescale slope and rescale intercept tags were not applied when a file was written back out with GDCMImageIO. When writing an image, DICOM tags are often partially re-used, including the tags that specify the on-disc representation. So, it is often desirable to re-apply the rescale intercept / slope tags. To do so, make sure the itk::ImageFileWriter or itk::ImageSeriesWriter instance uses a GDCMImageIO with the correct InternalComponentType. This can be achieved by re-using the GDCMImageIO instance applied when reading.