We recently encountered Lossless jpeg 2k dicom instances that were created by dcm4che.
The transfer syntax of the original is JPEG2000LosslessOnly and dcm4che sets the PhotometricInterpretation as YBR_RCT.
Orthanc is unable to render these images through the GDCM plugin. The following message is printed in the logs.
W0416 14:45:20.595030 HTTP-39 PluginsManager.cpp:157] Cannot decode image using GDCM: Unsupported output photometric interpretation
E0416 14:45:20.597036 HTTP-39 OrthancException.cpp:61] Not implemented yet: The built-in DCMTK decoder cannot decode some DICOM instance whose transfer syntax is: 1.2.840.10008.1.2.4.90
I did some experimenting. If I use dcm4che dcm2dcm tool to convert a jpeg dicom to jpeg lossless, dcm4che sets PhotometricInterpretation as YBR_RCT. However orthanc is unable to render these images.
If you use orthanc to transcode these images to jpeg, the jpeg colours are all muddled up.
If you use orthanc to transcode these to jp2k, PhotometricInterpretation is updated to RGB and the image can now be rendered.
First, I tried to upload original.dcm4che.jp2k.dcm to an Orthanc without IngestTranscoding and call /preview. Since I’m running in debug, I get a warning from GDCM:
Warning: In /home/alain/o/build/orthanc-gdcm/GDCM-prefix/src/GDCM/Source/MediaStorageAndFileFormat/gdcmJPEG2000Codec.cxx, line 802, function std::pair<char*, long unsigned int> gdcm::JPEG2000Codec::DecodeByStreamsCommon(char*, size_t)
Invalid PhotometricInterpretation, should be RGB
Then, I fixed the PhotometricInterpretation in the file and re-uploaded into Orthanc:
And after this, the /preview works ok in Orthanc and I can still view it in Radiant as well !
Given these findings, I have not played with the other files or with IngestTranscoding.
If you have enabled IngestTranscoding, I think the only solution to fix this inside Orthanc is to modify the instance before it is transcoded in this python callback.
So that makes me think that either PhotometricInterpretation=YBR_RCT is a valid possibility for these images, in which case I should look at seeing if it is possible for the GDCM plugin to support rendering jp2k images with PhotometricInterpretation=RBG or YMR_RCT.
Or
It is not valid, in which case it should be reported to dcm4che.
I’m not familiar enough with the specifics of colour encodings/PhotometricInterpretation to know the answer.
I’m actually not really familiar with PhotometricIntepretation values out of MONOCHROME and RGB
From what I read in GDCM code, MCT (Multi Component Transformation) flag is set to 0 which is not compatible with YBR_RCT but is valid for RGB.
Now it’s not possible for me to tell if it’s a GDCM bug when decoding the data or a DCM4CHE bug when encoding. I would suggest you to ask on their respective support.
