Re: Principles of HDR in chrome

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