- From: Fredrik Hubinette <hubbe@google.com>
- Date: Mon, 20 Nov 2017 10:54:14 -0800
- To: tim.borer@bbc.co.uk
- Cc: Jim Helman <jhelman@movielabs.com>, Lars Borg <borg@adobe.com>, "public-colorweb@w3.org" <public-colorweb@w3.org>
- Message-ID: <CAEVbG5p4kg2NbRxxJ_u2+ivy7E2SRBHS8txXFvdnMWTQ_eJP0w@mail.gmail.com>
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 > <(408)%20536-2723> | c. 408.391.9479 <(408)%20391-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 > <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1A__vvTDKXt4qcuCcSN-vLzcQKuchnYmu8TFMDseIZJE%2Fedit&data=02%7C01%7C%7Cdba9496e037b4cfc119508d52c826617%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636463860929188987&sdata=LFsiNCMAm%2BEJ75Qhu4JgTzo6Of1FJuRWPm%2F6JT3ezyU%3D&reserved=0> > > 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 18:54:42 UTC