Re: PQ HDR in PNG - draft review

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?

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

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

Received on Saturday, 20 May 2017 21:32:02 UTC