Re: Principles of HDR in chrome

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