RE: PQ HDR in PNG - draft review

The challenge of implementing HLG is step 4 (which cannot be done using 1D luts and matrices).  Therefore using segmented curves and matrix elements alone within iccMAX cannot be made to work.

However, it can easily be implemented in iccMAX using a simple script in a calculator element which would choreograph the application of segmented curves with additional logic to determine Y_s, then apply a luminance based gamma and multiply the result by the RGB values and finally apply the RGB to 2020 XYZ matrix.

Is there an HLG inversion somehow specified to enable one to get back to where you started?

Max Derhak (PhD)
Principal Scientist

From: Lars Borg [mailto:borg@adobe.com]
Sent: Friday, May 26, 2017 1:48 PM
To: Lars Borg; Manish Pindoria; Max Derhak; Fredrik Hubinette
Cc: Chris Lilley; public-colorweb@w3.org; Tim Borer
Subject: Re: PQ HDR in PNG - draft review

Rendering to display for HLG requires a multi stage transform:

  1.  Square & log curves in segments
  2.  RGB  to Y conversion
  3.  peak display luminance to gamma value
  4.  Multiply RGB with Gamma correction term using Y and above gamma
  5.  Matrix RGB from 2020 to XYZ
Is this doable in ICCMax?

Lars

On 5/26/17, 10:39 AM, "Lars Borg" <borg@adobe.com<mailto:borg@adobe.com>> wrote:

Any log base will work, as that's just a scale factor.
Are you rendering to scene or display space?
Hopefully to the latter.

Lars

On 5/26/17, 8:42 AM, "Manish Pindoria" <manish.pindoria@bbc.co.uk<mailto:manish.pindoria@bbc.co.uk>> wrote:

Hi Max, All,

Sorry for the delayed reply.

To answer the question below, HLG requires a natural log, as that is how it is defined in BT.2100. If you have any specific questions regarding HLG, please fire them over, Tim Borer (co-inventor of HLG) should hopefully be joining this group soon.

Best regards,

Manish

_______________________
Manish Pindoria
Senior R&D Engineer

BBC Research & Development
BBC Centre House, 56 Wood Lane, London, W12 7SB

T:  +44 (0)3030 409657
M: +44 (0)7714 957050
E:  manish.pindoria@bbc.co.uk<mailto:manish.pindoria@bbc.co.uk>



From: Max Derhak [mailto:Max.Derhak@onyxgfx.com]
Sent: 20 May 2017 15:13
To: Fredrik Hubinette <hubbe@google.com<mailto:hubbe@google.com>>; Lars Borg <borg@adobe.com<mailto:borg@adobe.com>>
Cc: Chris Lilley <chris@w3.org<mailto:chris@w3.org>>; public-colorweb@w3.org<mailto:public-colorweb@w3.org>
Subject: RE: PQ HDR in PNG - draft review

I believe that HLG can be expressed using iccMAX profiles using the two formulas in a segmented curve.  Does HLG require a natural log or will log base 10 work?

Max Derhak (PhD)
Principal Scientist

From: Fredrik Hubinette [mailto:hubbe@google.com]
Sent: Friday, May 19, 2017 5:55 PM
To: Lars Borg
Cc: Chris Lilley; public-colorweb@w3.org<mailto:public-colorweb@w3.org>
Subject: Re: PQ HDR in PNG - draft review

While ICCMax does have proper ways to describe PQ, it seems to do so in a way that is not easy to understand and implement.  Recent work to support ICC profiles in chrome has focused on ICC version 2, because ICC version 4.x is too difficult to implement efficiently, and ICCMax looks much more difficult. Since we don't know what the uptake on ICCMax will look like, having a special bit for HDR content might not be a bad idea. (However, the proposed magic string solution doesn't sound like a good idea.)

Another problem altogether is that PQ as a transform is defined in absolute lumens. Since non-HDR images are all in screen-relative brightness, it's impossible to make an PQ image which looks the same as a non-HDR image. To observe this problem in practice, hook up a recent Win10 machine with an HDR-capable graphics card to an HDR-capable tv and turn on HDR.  Suddenly all legacy apps become dark and gray, as windows translates them to 80 nits. Most people quickly turn HDR off again.

A better solution is probably to use hybrid-log-gamma, which uses screen-relative brightness. I'm not sure if there is an ICC(Max) profile that describes HLG accurately though.

      /Fredrik "Hubbe" Hubinette (Chrome HDR Video)


On Thu, May 18, 2017 at 8:04 PM, Lars Borg <borg@adobe..com<mailto:borg@adobe.com>> wrote:
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