Issues with jpeg 2000 and `encode_frame`

[erikogabrielsson]

Looking at the encode_frame-method i can see some issues:

• In DICOM Jpeg 2000 encoded frames should not be in JP2 format, which is the default when saving using Pilow. "no_jp2": True should be added to the settings.
• If I understand the parameter description correctly, photometric_interpretation is the intended color format in the output frame. The current implementation only allows YBR_FULL for color data, and the allowed values are YBR_RCT, YBR_ICT, YBR_FULL and RGB. According to the standard RGB and YBR_FULL should not have any component transform, while YBR_RCT and YBR_ICTshould. To get Pillow to do the component transform to YBR, you need to add "mct": True to the settings.

The parameters for saving Jpeg 2000 with Pillow is described here.

Not sure about the intended use of the encode_frame-method, but as it is used in highdicom to produce PixelData elements at least the jp2-issue should be fixed.

[CPBridge]

Hey @erikogabrielsson, I'm sorry that I somehow totally missed this until now. Thank you for letting us know about this.

For the first point, I have created #280. Could you please let me know whether this looks good to you?

For the second point, I am not really understanding. Currently the implementation only supports certain photometric interpretations and will raise an error if you try to specify one that is not supported for the combination of other parameters that you have chosen. Are you just suggesting that we may want to enable YBR_RCT and YBR_ICT for reversible and irreversible multi-component transform, respectively, or is there actually an issue with the current implementation of the supported photometric interpretations?

[erikogabrielsson]

Hi @CPBridge, No problem with the delay.

1. It looks good'.
2. From what I remember, my issue was "maybe also YBR_RCT and YBR_ICT should be supported" :)

[CPBridge]

The first point has now been resolved with #280, which will be inthe next release.

We do not have plans at this time to support the other photometric interpretations, since they are not widely used at the moment, so I am closing this issue. If people can point to a use case for those values, then it may be worth implementing them, but I do not know of any