Notes mainly for myself for further investigation:
In case we don’t want to modify the transcoding behavior and return the new PhotometricInterpretation in /metadata:
DCMTK provides a method to get the PhotometricInterpreation of the decompressed image:
OFCondition DcmPixelData::getDecompressedColorModel(
DcmItem *dataset,
OFString &decompressedColorModel)
We could call it when providing the /metadata (but that’s really not easy to call that code from the DicomWeb plugin). Here’s a possible solution:
- when the DicomWeb plugin requests the /tags for the /metadata route, it could specify the accepted transfer-syntax header
- Orthanc core would detect if decompression would happen based on the initial transfer syntax and the accept transfer-syntax
- Orthanc core would then call getDecompressedColorModel and modify the PhotometricInterpretation of the returned /tags
- Clients would have to specify the expected transfer-syntax when requesting the /metadata → not sure this is standard compliant (of course, if not specified, Explicit TS would be choosen)
- this method decodes the first frame to check if its PhotometricInterpretation has been modified → not optimal at all in terms of performance !
Tried to avoid the color space conversion during transcoding
No luck so far since it seems in DCMTK we can only register one global JPEG decoder and therefore we have to choose if it performs color space conversion or not at Orthanc level ! (reference to the question asked in the DCMTK forum)
Note: The DicomWeb standard says :
Some Attributes of the DICOM Dataset may depend on the Representation, not the Resource, especially those that describe the Pixel Data, so may differ from those encoded in a particular retrieved Representation. E.g., Photometric Interpretation (0028,0004) may differ depending on the Transfer Syntax.