Re: Principles of HDR in chrome

I didn't mean to apply that SDR mapping should be *fixed*.
Letting the content specify how the mapping works is perfectly reasonable
and not
in conflict with the idea that the composited image is considered
appropriate for a
reference (mostly dark) environment.

I think we agree in principle on how things should work, except that I
think that
the OS or application sometimes needs to pick up the slack where the display
system doesn't do what we want.

     /Hubbe


On Mon, Nov 20, 2017 at 11:07 AM, Pierre-Anthony Lemieux <pal@sandflow.com>
wrote:

> Hi Frederik,
>
> > SDR should be mapped into HDR as when played in a reference environment,
>
> As detailed in the latest TTML2 WD [1] and reflected in current home
> video mastering practices, the author should be able to scale the
> absolute luminance of an sRGB image when compositing an sRGB image
> onto an absolute luminance image plane, e.g. one derived from a PQ
> image. This should happen before any luminance adjustment/tone mapping
> is made on the final composited image by the display system. In other
> words, practice has demonstrated that using 80 nits for peak white
> when compositing sRGB onto PQ images does not yield acceptable
> results.
>
> Let me know if you need additional information.
>
> Best,
>
> -- Pierre
>
> [1] https://www.w3.org/TR/ttml2/#style-attribute-luminanceGain
>
> On Mon, Nov 20, 2017 at 10:54 AM, Fredrik Hubinette <hubbe@google.com>
> wrote:
> > Thanks everybody for pointing out the HLG issues. In my mind I never
> meant
> > to apply that HLG just hard-clips the signal, and I will update the
> > document.
> >
> > So far I haven't seen anybody comment on the major conclusion though:
> >
> > SDR should be mapped into HDR as when played in a reference environment,
> the
> > composited result should then be adapted to the viewing environment.
> (Which
> > in a bright environment means that both HDR and SDR are made brighter.)
> >
> > If this conclusion is completely incorrect, then I should just scrap the
> > document instead of working on fixing the inaccuracies.
> >
> >      /Fredrik 'Hubbe' Hubinette
> >
> >
> > On Mon, Nov 20, 2017 at 3:52 AM, Tim Borer <tim.borer@bbc.co.uk> wrote:
> >>
> >> Good points from Jim,
> >>
> >> I would add that for Jim’s first use case the situation will be
> different
> >> for live and post produced content. With live content there has to be an
> >> automatic algorithmic conversion, without human intervention, for low
> >> latency and, typically, because there are likely to be many streams and
> >> requirement for manual intervention would be impractical and/or
> >> prohibitively expensive.
> >>
> >> Best regards,
> >> Tim
> >>
> >> On 20/11/2017 08:07, Jim Helman wrote:
> >>
> >> Hi Lars & Frederick,
> >>
> >> Yes, the inconsistent practices are a big problem.
> >>
> >> First, on nomenclature, I describe the problem as how to encode an SDR
> >> signal in an HDR container. Mapping SDR content to HDR is a broader
> issue
> >> that can involve attempts to make the SDR content HDR with inverse tone
> >> mapping.
> >>
> >> I see at least two principal use cases. There are certainly others.
> >>
> >> 1) A content provider converts SDR content into an HDR format because
> the
> >> distributor plans to distribute it in an HDR signal, e.g., broadcast on
> an
> >> HDR channel. For graded content with creative control, the conversion
> may
> >> vary with the content and creative input. In many cases, the studio will
> >> want control over the conversion, and the white mapping may vary
> depending
> >> on the type of content or creative choice.
> >>
> >> 2) A box or system takes as its input a mixture of SDR and HDR content
> and
> >> needs to automatically convert it to an HDR format, e.g. a player device
> >> that wants to keep the TV in a single mode like 2160p60 PQ. This needs
> to be
> >> done algorithmicly without metadata, and if it's a fixed,
> >> content-independent mapping, a single practice on mapping SDR white
> should
> >> be defined.
> >>
> >> We're working on some proposed practices around #2.
> >>
> >> Cheers,
> >>
> >> -Jim
> >>
> >> On 11/18/17 1:24 AM, Lars Borg wrote:
> >>
> >> Hi Fredrik,
> >>
> >> Great write-up.
> >>
> >> A few comments:
> >> The broadcast industry has not come to an agreement of how to map SDR
> >> white to HDR in media
> >> Some big studios map SDR white to PQ 300 nits in media such as Blu-ray
> >> Disc as 300 nits is a typical consumer TV.
> >> Many HDR10 trailers seem to be at 200 or 300 nits.
> >> Other studios map SDR white to PQ 100 nits as that’s a reference monitor
> >> spec.
> >> Some big broadcasters and equipment vendors map SDR white and titles to
> >> HLG 75% code value (~200 nits)
> >> Other program creators map SDR white and titles to HLG  100 nit (and it
> >> looks dark).
> >> Many producers want options to set SDR white to 200 or 300 nits in HDR
> (PQ
> >> or HLG).
> >> A broadcast standard for average brightness is needed or else channel
> >> surfing and commercial breaks will be unpleasant experiences with
> varying
> >> brightness levels. Compare this with the CALM act for audio levels.
> >> Hopefully the industry will come to such an agreement within a few
> years.
> >> Obviously Chrome will not set this standard, but will need means to
> >> support it.
> >>
> >> Thanks,
> >>
> >> Lars Borg  |  Principal Scientist  |  Adobe  |  p. 408.536.2723  |  c.
> >> 408.391.9479  |  borg@adobe.com
> >>
> >>
> >>
> >> From: Fredrik Hubinette <hubbe@google.com>
> >> Date: Wednesday, November 15, 2017 at 1:40 PM
> >> To: "public-colorweb@w3.org" <public-colorweb@w3.org>
> >> Subject: Principles of HDR in chrome
> >> Resent-From: <public-colorweb@w3.org>
> >> Resent-Date: Wednesday, November 15, 2017 at 1:41 PM
> >>
> >> First of all, I wanted to thank everybody who attended the colorweb
> >> discussion at TPAC. It was very interesting and helpful. I wanted
> everybody
> >> who was there (and everybody who wasn't) to have another chance to give
> me
> >> feedback on the documented I presented there, now that we've had some
> more
> >> time to think about it. Here is the actual document:
> >>
> >>
> >> https://docs.google.com/document/d/1A__vvTDKXt4qcuCcSN-
> vLzcQKuchnYmu8TFMDseIZJE/edit
> >>
> >> I apologize in advance for any inaccuracies in here.
> >> I you have comments, either share them on this list, or you can request
> >> comment access.
> >>
> >> My next step is to bring the potential need for better brightness
> >> adjustment to industry groups. As pointed out in the meeting, the
> browser is
> >> not the right place for doing these adjustments, and if I can get OS or
> >> display makers to agree with me, then I won't have to implement it in
> >> Chrome, which would be great.
> >>
> >>     /Fredrik "Hubbe" Hubinette
> >>
> >>
> >>
> >
>