Why visualize DICOM file with pyDICOM and matplotlib return an greenish colour image

Question

I have a DICOM file with an image that I would like to visualize. The image looks fine when I opened with DICOM software. However, when I tried to visualize the image in python with pyDICOM using the following code:

ds = dcmread("1.2.826.0.1.3680043.214.533944214201189834015365840769154197151.dcm")
pix = ds.pixel_array
plt.imshow(pix, cmap=plt.cm.bone)

The image turn greenish. Here is the image exported in JPEG with the correct color from the same DICOM file.

These are the metadata of this DICOM file:

(0022, 001b)  Refractive State Sequence  0 item(s) ---- 
(0028, 0002) Samples per Pixel                   US: 3
(0028, 0003) Samples per Pixel Used              US: 2
(0028, 0004) Photometric Interpretation          CS: 'RGB'
(0028, 0006) Planar Configuration                US: 0
(0028, 0008) Number of Frames                    IS: "1"

Could you please help me to visualize the DICOM image with the correct color.

Answer 1

It appears that you are trying to visualize a JPEG (ITU 81) compressed DICOM file. According to the Photometric Interpretation value you gave us, it looks like Lossless compressed.

In any case the fact that the image is displayed with a greenish aspect is most likely caused by an inconsistency in between the color space indicated by the DICOM Photometric Interpretation and the actual color space indicated by the encapsulated Pixel Data JPEG stream.

Here is a small experiment you can try at home with your DICOM file:

$ sudo apt-get install libgdcm-tools
$ gdcmraw 1.2.826.0.1.3680043.214.533944214201189834015365840769154197151.dcm /tmp/pixel_data_stream.jpg
$ file /tmp/pixel_data_stream.jpg 
/tmp/pixel_data_stream.jpg: JPEG image data
$ gdcmimg /tmp/pixel_data_stream.jpg /tmp/dicom.dcm
$ gdcminfo /tmp/dicom.dcm
[...]
TransferSyntax is 1.2.840.10008.1.2.4.70 [JPEG Lossless, Non-Hierarchical, First-Order Prediction (Process 14 [Selection Value 1]): Default Transfer Syntax for Lossless JPEG Image Compression]
NumberOfDimensions: 2
Dimensions: (256,256,1)
SamplesPerPixel    :3
BitsAllocated      :16
BitsStored         :16
HighBit            :15
PixelRepresentation:0
ScalarType found   :UINT16
PhotometricInterpretation: RGB 
PlanarConfiguration: 0
TransferSyntax: 1.2.840.10008.1.2.4.70
[...]

The goal of the experiment was to verify what was the actual color space as found in the JPEG bitstream. By removing the DICOM enveloppe (gdcmraw step), we make sure that gdcmimg step will have no access to the DICOM Photometric Interpretation value and should deduce the right value directly from the JPEG stream itself.

In other word, if gdcmimg reconstruct a DICOM file with a Photometric Interpretation different from the one as found in the original file, then you found your issue.

If you have access to the DCMTK toolkit, in particular dcmdjpeg, pay attention to the following advanced process option:

$ man dcmdjpeg
[...]
   processing options
       color space conversion:

         +cp   --conv-photometric
                 convert if YCbCr photometric interpretation (default)

         # If the compressed image uses YBR_FULL or YBR_FULL_422 photometric
         # interpretation, convert to RGB during decompression.

         +cl   --conv-lossy
                 convert YCbCr to RGB if lossy JPEG

         # If the compressed image is encoded in lossy JPEG, assume YCbCr
         # color model and convert to RGB.

         +cg   --conv-guess
                 convert to RGB if YCbCr is guessed by library

         # If the underlying JPEG library "guesses" the color space of the
         # compressed image to be YCbCr, convert to RGB.

         +cgl  --conv-guess-lossy
                 convert to RGB if lossy JPEG and YCbCr is
                 guessed by the underlying JPEG library

         # If the compressed image is encoded in lossy JPEG and the underlying
         # JPEG library "guesses" the color space to be YCbCr, convert to RGB.

         +ca   --conv-always
                 always convert YCbCr to RGB

         # If the compressed image is a color image, assume YCbCr color model
         # and convert to RGB.

         +cn   --conv-never
                 never convert color space

         # Never convert color space during decompression.

Once your compressed DICOM file is decompressed by dcmdjpeg, the inconsistency in between the DICOM enveloppe and the JPEG bitstream is removed (only the Photometric Interpretation of the DICOM header can indicate the color space).

---

If you really want to keep your DICOM file with the original compressed bit stream. You may be able to fix the Photometric Interpretation value using something like this:

$ gdcmanon --dumb --replace 0028,0004=YBR_FULL 1.2.826.0.1.3680043.214.533944214201189834015365840769154197151.dcm /tmp/corrected.dcm

Or (if the compression is lossy):

$ gdcmanon --dumb --replace 0028,0004=YBR_FULL_422 1.2.826.0.1.3680043.214.533944214201189834015365840769154197151.dcm /tmp/corrected422.dcm

Answer 2

When the DICOM transfer syntax is 1.2.840.10008.1.2.4.70 (Jpeg lossless) the photometric interpretation shouldn't be RGB but one of the YBR (YBR_FULL or YBR_PARTIAL or the chroma subsampled versions).

Despite the DICOM standard allowing for the RGB color space with jpeg lossy images, I've never seen a jpeg lossy image with the RGB color space that was rendered correctly in RGB (but was rendered just fine as soon as the color space was replaced by YBR).

There are several DICOM datasets out there that have this mistake and the only way to show them correctly is to replace RGB with YBR_FULL or the subsampled YBR_FULL_422.