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:
Samples per Pixel
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 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
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
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.184.108.40.206.2 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.220.127.116.11.3 Derivation Description):
Examples of Derived Images which would normally be expected to affect professional interpretation and would thus have a new UID include:
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.
SOP Instance UIDof the original in
Source Image Sequence.
Image Typevalue 1 to
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
SOP Instance UID. In most case you should expect that the
image is not resent, as standard garantee this is already the same
Adding an overlay is considered to affect professional interpretation of the images. Thus new UIDs are required !