Re: PQ HDR in PNG - draft review

What is luminance matching intended to be used for?

     /Hubbe

On Sat, May 20, 2017 at 6:22 AM, Max Derhak <Max.Derhak@onyxgfx.com> wrote:

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