Rec. 2100

[kevinloch]

Rec. 2100 uses the Rec. 2020 colorspace but specifies two new transfer functions to support HDR: PQ, and HLG

Is it possible to encode either of these in a v4 profile?

HLG was designed to be more "backwards compatible" with earlier transfer functions but PQ can encode 10x the peak brightness and seems to have the best adoption for HDR use cases.

[saucecontrol]

There's a new tag type cicpType in the latest v4.4 spec update that can be used to tag video encoding. Its values specifically include tagging for PQ and HLG data, but I'm not clear how it's supposed to interact with the normal response curve tags, as those don't allow the formulas for PQ nor HLG to be represented. It would be possible to define a LUT-based curve for them, but the precision would be an issue because of the wider value range.

Is there any specific software you're looking to use such a profile with? If I saw some real-world examples of profiles or how they're used, I'd feel more confident creating something.

[kevinloch]

I'm not clear how it's supposed to interact with the normal response curve tags

My guess is clients are supposed to ignore the legacy TRC data if PQ or HLG is indicated, since those already refer to very specific formulas. If the legacy tags can't be omitted then a flat 1.0 curve might be a good placeholder.

I'd like to try a PQ/HLG signaled profile on 16-bit PNG renderings in https://github.com/kevinloch/bsrender My hope is that will enable HDR display on at least some clients using the widely supported PNG container.

Floating-point OpenEXR images with pixel data > 1.0 are rendered in HDR on late model Mac's, even though OpenEXR doesn't support TRC or ICC profiles. Unfortunately OpenEXR is not supported by any web browser so it's not practical to share them widely.

I also found this: https://prolost.com/blog/edr which shows an HLG encoded video displaying in HDR mode on Mac.

[saucecontrol]

If the legacy tags can't be omitted then a flat 1.0 curve might be a good placeholder.

I think this would probably be a bad idea, because non-HDR software would then display the image incorrectly, without any indication that it's doing so. It's generally best to either provide a reasonable compatibility fallback (progressive enhancement) or to make display fail unless the software is compatible.

The new HDR JPEG format takes the former approach, which I'm hoping will catch on.

I also found this: https://prolost.com/blog/edr which shows an HLG encoded video displaying in HDR mode on Mac.

Video formats have taken the latter approach, in part because HDR and UHD go hand in hand. The newer advanced codecs have HDR and the associated metadata coded in the spec so that there are no non-compliant decoders.

That said, I still haven't found any good info on the intended use of ICC's cicpType, so I don't know which approach it's meant to be used with.

[saucecontrol]

I'd like to try a PQ/HLG signaled profile on 16-bit PNG renderings in https://github.com/kevinloch/bsrender My hope is that will enable HDR display on at least some clients using the widely supported PNG container.

I just ran across an interesting collection of HDR PNG images at https://old.lucaversari.it/jpeg_xl_data/jpeg_xl_png/

The ones I looked at (the ClassE examples) use ICC v4 LUT profiles with Lab connection space, which allows encoding of L values up to 255 (100 being SDR white), and they seem to display correctly in Chrome as well as Windows Photo Viewer on an HDR display.

[saucecontrol]

I finally found the document that describes use of cicpType: https://color.org/groups/hdr/CICP_Votable_Proposal_2020-12-08.pdf. It's intended as a bridge between imaging and video software, essentially giving video software permission to ignore the profile and substitute its own color management for a known color space. So it's more of a compatibility augmentation for HDR formats than a description of the formats themselves.

I also found a newer Rec.2100 PQ profile from Apple (ex: https://cdn.lonjil.xyz/fdbcefe61c89d335/pfW9ODQ.jpg). Like the one in the PNG examples linked above, it uses the a2b0 tag to define the conversion, but it does so by means of multiple 1D curves, making it a more accurate approximation than the 3D LUT alone. It also includes a cicp tag. This would seem to be the current best practice.

[kevinloch]

This does sound like the best approach. I'll add code to do the PQ transform in bsrender, and will test with the Apple profile.

[kevinloch]

The profile extracted from pfW9ODQ.jpg works compatibly on all browsers i've tried on mac, and displays with full HDR range with the Chrome browser on an M2 macbook.

Edit: just realized I was looking at the cicp label in the tag table and not the actual tag. The actual tag (at profile offset 33d4) is exactly as expected:

0x63 0x69 0x63 0x70 0x00 0x00 0x00 0x00 0x09 0x10 0x00 0x01

I'm working on a minimal open source profile with just cicp and the other required tags for testing.

[kevinloch]

Here's my experimental test profile: rec2100pq-experimental.zip.

It uses the same matrices and TRC as your Rec2020Compat-v4.icc but with the cicp and lumi tags added:

cicp (Rec. 2100 PQ full-range) 0x63 69 63 70 00 00 00 00 09 10 00 01

lumi (ref=100 nits) 0x58 59 5a 20 00 00 00 00 00 00 00 00 00 64 00 00 00 00 00 00

The lumi tag is required (at least on Chrome/M2 mac) but it's value doesn't change the display so I left it at 100 which appears to be a standard default.

Using the Rec2020 curves obviously does not approximate the PQ function so images on unsupported viewers are washed out/fuzzy. I found that helpful for development as it is really obvious if the viewer is using the cicp/lumi tags or the encoded TRC.

Sample image using this profile: https://bsrender.io/sample_renderings/pleiades-m17-hdr500-2k.jpg