Re: Principles of HDR in chrome

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 <mailto:hubbe@google.com>>
> Date: Wednesday, November 15, 2017 at 1:40 PM
> To: "public-colorweb@w3.org <mailto:public-colorweb@w3.org>" 
> <public-colorweb@w3.org <mailto:public-colorweb@w3.org>>
> Subject: Principles of HDR in chrome
> Resent-From: <public-colorweb@w3.org <mailto: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 08:07:53 UTC