Re: PQ HDR in PNG - draft review

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

Received on Saturday, 20 May 2017 04:21:04 UTC