Re: PQ HDR in PNG - draft review

That doesn't seem unreasonable, but it doesn't address the fact that most
(all?) existing HDR TVs
map SDR white and a 80-nits-encoded PQ signal completely differently.

  /Hubbe

On Fri, May 19, 2017 at 11:52 PM, Lars Borg <borg@adobe.com> wrote:

> Isn’t the intent that 80 nits is to be used in a reference monitor
> situation?
>
> And if I make my display brighter, everything scales with it.
>
> So a 300 nit SDR TV is 3x reference, thus make everything 3x brighter?
>
> Lars
>
> On 5/19/17, 6: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.
> >
> >A default of sRGB 80 nits peak white might not be the right answer for
> >general UI/web page work.
> >
> >> > 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?
> >
> >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://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Fw3c.git
> >>>hub.io%2Fttml2%2Fspec%2Fttml2.html%23style-
> attribute-luminanceGain&data=
> >>>02%7C01%7C%7C2fba752906a349f2678608d49f378d58%
> 7Cfa7b1b5a7b34438794aed2c1
> >>>78decee1%7C0%7C0%7C636308508321186664&sdata=
> igxWqDbB0Q75ZJUQdf88JAb1Hm%2
> >>>BvM964enDL8jCWpDw%3D&reserved=0
> >>>
> >>> > 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
> >>> >
> >>> >
> >>
> >>
>
>