Re: PQ HDR in PNG - draft review

Hi Frederik et al.,

>  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.

One approach is to specify an (optional) gain value to scale the SDR
image before compositing it onto HDR images.

This is the approach taken in recent TTML2 [1] draft, and has the
advantage of giving the author control because, sometimes, the white
point of the SDR image should be at 80/100 nits.

[1] https://w3c.github.io/ttml2/spec/ttml2.html#style-attribute-luminanceGain

> Suddenly all legacy apps become dark and gray, as windows translates them to 80 nits.

Using 80 nits as the default white point for SDR images is certainly
safe and conservative, but not appropriate in all cases. I think this
is an industry discussion, which hopefully we can have.

Hope this makes sense.

Best,

-- Pierre

On Fri, May 19, 2017 at 2:55 PM, Fredrik Hubinette <hubbe@google.com> wrote:
> 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> 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
>
>

Received on Friday, 19 May 2017 22:31:18 UTC