Re: PQ HDR in PNG - draft review

On Sat, May 20, 2017 at 3:49 PM, Pierre-Anthony Lemieux <pal@sandflow.com>
wrote:

> Hi Frederik,
>
> > I would prefer that the default was undefined.
>
> Ah. What would be your recommendation for system designers when
> compositing a full scale sRGB pixel onto a PQ image if no explicit
> luminance gain is provided?
>
> The reason to provide an explicit default in my mind is that some
> system designers chose in the past to map full scale sRGB to full
> scale PQ, which makes for unpleasantly bright subtitles/captions.
>
>
Unfortunately I think there needs to be a system setting for this, because
any particular value you pick is going to be the wrong value.


> > Correct. Which is why I suggesting that maybe we should have a different
> > tag which lets you specify absolute luminance.
>
> The "luminanceGain" tag is intended to be that tag :) It is used to be
> called absoluteLuminanceGain, but the group felt that 'absolute' was
> rendundant... or are you suggesting that the tag, instead of being a
> multiplier, outright specify the absolute luminance of the sRGB white
> point?
>
>
Yes. Because that would have no implication on how things that do not
have the tag should be rendered. If the goal is to match something that
has absolute luminance, then using an absolute value seems right.


> Best,
>
> -- Pierre
>
> On Sat, May 20, 2017 at 2:34 PM, Fredrik Hubinette <hubbe@google.com>
> wrote:
> >
> >
> > On Sat, May 20, 2017 at 2:31 PM, Pierre-Anthony Lemieux <
> pal@sandflow.com>
> > wrote:
> >>
> >> Hi Fredrik,
> >>
> >> I appreciate your bearing with me.
> >>
> >> > But using luminanceGain = 4 as a way to express that, implies that
> >> > luminanceGain = 1 should be 100 nits, which is the part that I think
> >> > is unfortunate.
> >>
> >> Are you arguing that the default should be 400 nits for subtitles
> >> instead of 80 nits?
> >
> >
> > I would prefer that the default was undefined.
> >
> >>
> >> > No, I meant that sRGB peak is mapped to some unknown number of nits,
> and
> >> > luminanceGain = 2 is twice as bright as that.
> >>
> >> That would not allow the author to precisely control subtitle light
> >> levels relatively to the PQ image, right?
> >>
> >
> > Correct. Which is why I suggesting that maybe we should have a different
> > tag which lets you specify absolute luminance.
> >
> >>
> >> Best,
> >>
> >> -- Pierre
> >>
> >> On Sat, May 20, 2017 at 2:14 PM, Fredrik Hubinette <hubbe@google.com>
> >> wrote:
> >> >
> >> >
> >> > On Fri, May 19, 2017 at 9:20 PM, Pierre-Anthony Lemieux
> >> > <pal@sandflow.com>
> >> > wrote:
> >> >>
> >> >>  Hi Fredrik,
> >> >>
> >> >> > I think it's confusing
> >> >> > to suggest that sRGB is 80 nits since almost all monitors in use
> >> >> > today
> >> >> > are
> >> >> > brighter than that.
> >> >>
> >> >>  A default of sRGB 80 nits peak white was chosen as the default in
> >> >> TTML2 because it is always safe when compositing subtitles onto full
> >> >> screen video: it is particularly jarring when subtitles are much
> >> >> brighter than the picture!
> >> >>
> >> >> In practice, subtitles are typically presented around 400 nits when
> >> >> composited onto PQ content, i.e. luminanceGain = 4, with occasional
> >> >> exceptions that are content dependent.
> >> >>
> >> >
> >> > I think it's fine to want 400 nits subtitles.
> >> > But using luminanceGain = 4 as a way to express that, implies that
> >> > luminanceGain = 1 should be 100 nits, which is the part that I think
> >> > is unfortunate.
> >> >
> >> >>
> >> >> A default of sRGB 80 nits peak white might not be the right answer
> for
> >> >> general UI/web page work.
> >> >>
> >> >
> >> > Agreed.
> >> >
> >> >>
> >> >> > > Would it be possible to drop the 80 lumens and just say that
> >> >> > > luminanceGain =
> >> >> > 2 is twice as bright
> >> >> > as the default?
> >> >>
> >> >> What do you mean by "default"? Is the suggestion that, by default,
> >> >> sRGB peak white be mapped to 160 nits?
> >> >>
> >> >
> >> > No, I meant that sRGB peak is mapped to some unknown number of nits,
> and
> >> > luminanceGain = 2 is twice as bright as that.
> >> >
> >> >>
> >> >> Best,
> >> >>
> >> >> -- Pierre
> >> >>
> >> >> On Fri, May 19, 2017 at 6:40 PM, Fredrik Hubinette <hubbe@google.com
> >
> >> >> wrote:
> >> >> > 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.
> >> >> > 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
> >> >> >> >
> >> >> >> >
> >> >> >
> >> >> >
> >> >
> >> >
> >
> >
>