- From: Fredrik Hubinette <hubbe@google.com>
- Date: Mon, 20 Nov 2017 11:28:59 -0800
- To: Pierre-Anthony Lemieux <pal@sandflow.com>
- Cc: Tim Borer <tim.borer@bbc.co.uk>, Jim Helman <jhelman@movielabs.com>, Lars Borg <borg@adobe.com>, "public-colorweb@w3.org" <public-colorweb@w3.org>
- Message-ID: <CAEVbG5rUut6u=ike71FA4ZbTakuof4d+26Dqdkm3wGn-=3Ofdg@mail.gmail.com>
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 > >> > >> > >> > > >
Received on Monday, 20 November 2017 19:29:28 UTC