Re: PQ HDR in PNG - draft review

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

Received on Saturday, 20 May 2017 06:53:28 UTC