Re: PQ HDR in PNG - draft review

Hi Chris,

I assume you’re looking at the profile that I created.
The profile was designed to provide a transform to/from Rec.2100 PQ to XYZ D50.
The only descriptive metadata included is the profile description, as that’s what’s being displayed in profile menus, etc.
No effort was made to add other descriptive metadata, as no such was asked for.

Elaborating on some of the ICC constraints that you’re observing.

The first thing I noticed is that there are no colorant tags to indicate the primaries used.

The colorant tag will not be used by the CMM.
One tricky thing is that the colorant values in this tag will not match the Rec. 2100 spec.
The colorant XYZ value has to be in PCS space, so it has to be chromatically adapted to D50.

There is a chromaticityType tag that can indicate the unconverted xy chromaticities from the Rec. 2100 spec.
Probably more useful.
The chromaticityType tag will not be used by the CMM.
This is purely descriptive metadata.


Although the specification itself does list the chromaticities of the 2020 primaries, they are not in the ICC profile.

They are embedded in the matrices in the A2B and B2A tags.


The second thing I noticed was that the lumi tag indicates a peak luminance of 100 cd/m^2 which does not sound like HDR at all.

True.
It’s not clear from the ICC spec that the lumi tag shall express peak luminance.
It is here set to match the luminance of the PCS white point.
A PQ value of 508, 508, 508 (/1023) corresponds to 100 nits.
This is also the reference SDR diffuse white, and was selected as the PCS white point for cross-media conversion.
The reason:
ICC profiles are used for converting between SDR and HDR.
No established practice exists for mapping colors between HDR and SDR.
Reference white for SDR in the studio is 100 nits.
But many consumer SDR displays operate at 300 nits, so some existing programs put diffuse white in HDR at 300 nits.
So the desired crossover between SDR and HDR is at 100 or 300 nits, definitely not at 1000 or 10,000 nits.
Time will tell.


There are A2B0 and B2A0 tags for the transfer functions. The B curve is linear, the M curve has a gamma of 5 and there is a slightly sigmoidal A curve. I am not able to tell whether this correctly represents the BT.2100 EOTF and would appreciate guidance here.

The dynamic range of the PQ curve (10^9) far exceeds the U16 code range available in an ICC sampled curves.
The high gamma in the M curve expands the dynamic range of the sampled A curve. (Established practice)
Thus, the A curve has a dynamic range of <100. This allows for almost 3 significant digits in the low end.
This results in a more accurate transform.


Eek! It looks as if a magic string is used to signal the image contents, and that string is the name of the ICC profile. Not only are the gamma and chromaticity to be ignored, but also the contents of the ICC profile.

Agreed. That looks horrible.

It seems clear that a vastly better way to encode BT.2100 still images in PNG would be to embed an ICCMax profile that correctly describes the EOTF and the primary chromaticities, and has a correct peak luminance value. I assume that the flaws noted above are due to limitations of ICC v.4?

Any obvious drawbacks of my proposed approach?

Have you created such an ICCMax profile?
How do you encode PQ EOTF?

1. I assume the profile is to be used for color conversions, and not only to signal a color space. The current profile works in tested contemporary CMMs and apps. Those same CMMs fail on ICCMax profiles. I am not aware of any plans to change that.
2. No way to map the content to SDR media as the 10,000 nits value is useless for this. The current ICC profile provides a fallback for SDR on existing systems.
3. Did you find any flaws related to ICC v4? It seems the mismatch between your expectations and the current implementation are not due to flaws in ICC v4, so we can simply update the ICC profile to address your needs.

How about adding descriptive metadata tags to a v4.2 profile?
The chromaticityType tag is already in the ICC standard.
Not sure how to indicate an EOTF in ICC.
Maybe the best is to indicate color and EOTF by name or enum instead of by value?
HEVC, etc. have adopted enumerations for a closed set of color tags. Here the values would be 9,16,0.

Lars