Re: Principles of HDR in chrome

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:08:02 UTC