Re: PQ HDR in PNG - draft review

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