I encountered some challenges writing color DICOM images to file using GDCMImageIO.
The current implementation of the GDCMImageIO assumes three channel images have a photometric interpretation value of RGB, see here. I have images that are YBR_FULL_422 and I would like to write them as such (the writer simply ignores my settings for this DICOM tag in the meta-data dictionary).
My question is, is this a bug or a feature?
If a bug, I would modify the writer to use the value of the photometric interpretation from the dictionary (RGB would remain as default if this tag isn’t in the dictionary).
If a feature, I would modify the documentation to say that the user should convert the color data to the RGB colorspace defined by the DICOM standard before writing to file.
I believe the resolution there was to define loading all color images as RGB images into ITK as the expected behavior. The YBR_FULL_422 encoding is an opponent color format which be considered a perceptually compressed pixel encoding giving more resolution to Brightness or Lightness where humans have the most discriminatory resolution. So one can consider it a compressed RGB image.
Apparently the above patch has not been updated and merged into ITK yet.
What is in the ITK Image buffer should be described by the ImageIO::PixelType(set in the ImageFileWriter) and in the meta-data dictionary. Unfortunately, the ImageIO::Pixel type does not support for opponent color spaces there.
I’m concluding that your proposal to describe the buffer with a DICOM specific metadata tag should not be done. Now there are other areas related to handling RGB encodings that certainly need cleanup, definitions and improvement where the big picture of consistent behavior needs to be considered.
I was reading about YBR_FULL_422, the opponent color channels are actually and 1/2 the resolution in “x” of the luminance (Y) channel. So technically, your ITK image is just YBR not in the 422 sampling.
As @blowekamp already mentioned above the data in ITK image is 888, greenish blue or not. Experimentally, with low level GDCM, is possible to generate lossy Jpeg (YBR_FULL_422) and RLE (YBR_FULL) files, not sure 100% that the files are ideal, in GDCM code are many comments and FIXMEs, @mathieu.malaterre knows more. Tested the files with many good viewers without problems.
Input for Jpeg before change transfer syntax was correct RGB, for RLE greenish blue 888. Again, all experimental.
Edit
many viewers can also open YBR_FULL in uncompressed data, it is not really legal, but i tried and many could open such file. Do get this just save greenish blue data (in ITK e.g.) and replace photometric interpretation with YBR_FULL, may work.
Edit
GdcmIO in ITK has RLE compression option (and doesn’t have lossy Jpeg), probably the best way to save YBR image were to use RLE compression with greenish blue data as input and set photometric interpretation manually to YBR_FULL. Should be valid file, i guess.
New with ITKv5 was exposing of several different compression options: JPEG, JPEG2000, JPEGLS, RLE.These compression options would be useful for histology images.
@mathieu.malaterre The issue I had was indeed with the ITK behavior (it ignored my settings in the meta-data dictionary for photometric interpretation, always writing it as RGB. The reason I wanted to use the YBR_FULL_422 setting was that the original images I got were saved as such and I needed to do some minor manipulation on them and save them back.
Per @blowekamp’s response, I can just save as RGB. I will add something to ITK’s GDCMImageIO documentation to say that it expects all 3 channel images to have a photometric interpretation of RGB and that the contents of the meta-data dictionary for this tag are ignored.
@blowekamp There is no lossy Jpeg compression in ITK’s GdcmIO writer, it were gdcm::TransferSyntax::JPEGBaselineProcess1 and we need correct RGB input for change transfer syntax, not greenish blue that we have after opening of one YBR_FULL_422 image. Lossy Jpeg is the only valid transfer syntax for YBR_FULL_422.
Edit: RLE is defined, but not used, there are only lossless Jpeg and Jpeg2000
