Failure to transfer restricted ICC display profile to opj_compress[ed] file

[comstock]

The JPEG2000 standard (part 1) was amended to support restricted ICC display profiles.

opj_compress should take an input image with an embedded display profile (e.g., Adobe RGB) and output a JP2 file with the same profile. Currently , opj_compress seems to ignore the input icc profile and output a JP2 file where color encoding is tagged, enumerated sRGB.

• Is this a known issue?
• Is this an issue queued for resolution with a openjpeg update?

Linked here is a test TIFF image with an unusual ICC profile embedded. A JP2 created from this TIFF will display the color names and colors aligned when viewed within a color managed application (e.g., Photoshop, Gimp).

-- thanks

[boxerab]

@comstock if you're interested in correct handling of ICC profiles, you can check out my library: https://github.com/GrokImageCompression/grok

[comstock]

Thanks so much. I've only tested it on one image but I am so pleased.

[boxerab]

JPEG,PNG and BMP ICC profiles are also supported by the encoder. And decoding to JPEG,PNG or TIFF will preserve an ICC profile stored in the compressed file.

[bitsgalore]

This also happens the other way round - consider below JP2 that has an embedded display profile:

https://github.com/openpreserve/format-corpus/raw/master/jp2k-test/icc/balloon_eciRGBv2_aware.jp2

Decompressing to TIFF (I'm using OpenJPEG 2.3.0) with:

opj_decompress -i balloon_eciRGBv2_aware.jp2 -o balloon_eciRGBv2_aware.tif

The ICC profile is then absent in the resulting TIFF image. Like @comstock I initially thought this had something to do with the profile being a 'display' profile (which was excluded from JP2 before the 2013 amendment), so as an additional test I hex-edited the value of the 'profile class' field in the ICC profile from 'mntr' (Display device profile) into 'scnr' (Input device profile), and then ran opj_decompress on the resulting file. But this gave me the same result (no ICC profile in the TIFF), so this seems unrelated to the amendment.

Weirdly I seem to recall that earlier OpenJPEG versions did actually support ICC profiles, which makes me wonder if the current behaviour is the result of some regression. But maybe my memory is wrong on this?

[cmhenshaw]

Just to resurrect this ticket... we are currently testing implementation of OJP in our conversion workflow (TIFF - JP2), and have discovered this issue which rather puts a dampener on things, as we use restricted ICC profiles for most of our special collection digitisation. What work is required to sort this out? @bitsgalore and @comstock any useful workarounds that you have come up with in the meantime?

[bitsgalore]

@cmhenshaw Not really, we're only using OJP for rendering access JP2s in our Delpher platform. In this case the ICC profiles are also ignored, which means colour rendering will be slightly off, but for in-browser display this isn't a critical issue (at least not for the colour spaces defined in the ICC profiles we're using). For a TIFF to JP2 conversion workflow this would be a definite show-stopper though (and added to that the fact that OPJ doesn't support resolution boxes).

BTW, in case you haven't seen it already, you might want to have a look at this blog post I wrote just yesterday, which shows that Grok does preserve ICC profiles, so this might be an alternative option.

[Beechwell]

Hello all, being the one tasked to implement the jp2 conversion @cmhenshaw has mentioned, I would also be rather urgently interested to know if there is any chance for this to be implemented at all in the nearer future. Because it is indeed kind of a dealbreaker for images that are used not only for browser display. I suppose we will also be evaluating whether grok may be a viable alternative for this workflow. Thanks @bitsgalore and @comstock for those notes on installing grok which I have been struggling with so far.