RE: PQ HDR in PNG - draft review

Interesting discussion.  I will be the first to recognize my understanding of the all the nuances of displays is lacking.  As part of the Resolution of Comments on the ISO balloting of ISO 20677 we are proposing the following addition to the PCS processing annex of the iccMAX spec (being presented in 3 weeks).  This provides a specified method for dealing with absolute luminance levels when desired.  I would be interested in any feedback from you.

A.1.10 Luminance Matching
The ISO 15076-1 standard colorimetric PCS as well colorimetric PCS values in this part of ISO 20677 are encoded in terms of normalized tristimulus values.  This means that tristimulus values are normalized to a reference white, which is assumed to be the adapted white point. For a surface colour this is a perfect white diffuser viewed under a D50 illuminant, for a display it is the assumed white point (often the display white point), and in both cases the values are scaled so that the tristimulus Y of the reference white is 1,0. (These are relative tristimulus values, as described in CIE.15.) One consequence of this normalization is that differences in luminance between source and destination are not accounted for when connecting a pair of profiles using a colorimetric PCS.

In some cases it may be desirable for the colour management goal to take the actual luminances of source and destination into account, and this can be accomplished by using luminance information from the profiles to provide a scaling of tristimulus values during PCS processing by the CMM. The absolute photometric luminance in cd/m2 can be provided in the CIE Y value of the illuminant field of the spectralViewingConditions tag (of a profile based on this part of ISO 20677) or the CIE Y value of the luminanceTag (of a profile based on ISO 15076-1).   When such tags are not available then the default luminance of 160 cd/m2 (associated with the perceptual PCS defined by ISO 15076-1, or the standard viewing condition P2 specified for graphic arts and photography in ISO 3664) can be used.  Additionally, an override of a profile’s luminance can be provided by the CIE Y value of the illuminant field of the spectralViewingConditions defined by alternate Profile Connection Conditions when they are provided to the CMM for a profile.

When luminance matching is desired, the instructed CMM performs a Colorimetric PCS operation that scales the tristimulus values by the ratio of the luminance associated with the source profile divided by the luminance associated with the destination profile.

An important caution related to the use of luminance matching is that clipping may occur when tristimulus values are scaled outside the range that the destination profile is capable of adequately handling.

Best Regards,

Max Derhak (PhD)
Principal Scientist

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

The TTLML2 gain value seems like a good idea. It is imilar in some sense to the wording
for how to deal with floats outside of 0-1 in the canvas-color-space<https://github.com/WICG/canvas-color-space/blob/master/CanvasColorSpaceProposal.md#the-pixelformat-context-creation-attribute>. However, I think it's confusing
to suggest that sRGB is 80 nits since almost all monitors in use today are brighter than that. It seems
like the tts:luminanceGain wording would lock legacy elements at 80 nits (aka "dark and dreary").

Would it be possible to drop the 80 lumens and just say that luminanceGain = 2 is twice as bright
as the default?

If we really need a way to match how PQ works, it might be better to have an absoluteLuminance
tag instead.  But personally I would prefer not to deal with absolute luminance as that is not compatible
with how I use my TV and monitor.

     /Hubbe

On Fri, May 19, 2017 at 3:30 PM, Pierre-Anthony Lemieux <pal@sandflow.com<mailto:pal@sandflow.com>> wrote:
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<mailto: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<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
>
>