Re: Principles of HDR in chrome

Hi Fredrik & Lars,

A good write up thanks, but with a few misunderstandings. I attach a 
commented version for your consideration.

The place where I have a disagreement is in your section about the 
“clipping problem”, which seriously misrepresents the BBC’s position. 
The BBC does not, and never has, advocated simply clipping the HDR to 
whatever the display can handle. Indeed it is difficult to see how the 
HLG standard could be interpreted that way. Firstly the HLG signal is 
NOT designed to be displayed only at 1000 nits. It is specifically 
designed so that it may be rendered on a variety of display brightnesses 
under a range of viewing environments. What we have said, and what is in 
ITU-R BT.2100, is that you scale the relative scene light represented by 
the HLG signal and, at the display, you apply a gamma curve when 
rendering the signal to allow for psychovisual effects. BT.2100 
specifies the gamma value to use in reference viewing conditions (which 
is based on numerous psycho-visual subjective tests). Details are in the 
references given by Simon Thompson, and an improved equation, which fits 
the data better at high and low display luminance, is given in "Display 
of high dynamic range images under varying viewing conditions", Proc. 
SPIE 10396, Applications of Digital Image Processing XL, 103960H (19 
September 2017); doi: 10.1117/12.2274253; 
http://dx.doi.org/10.1117/12.2274253.
The key point is that HLG is expressly designed to be rendered under 
various viewing conditions and we would certainly not advocate clipping.

Regarding the issue of how to map SDR white to HDR in media there is, 
now, a great deal of agreement on how this should be done. The key issue 
is where to place "diffuse white" in HDR signals. This has been agreed 
in a recently published ITU-R Report, BT.2408 "Operational practices in 
HDR television production" (freely available at 
http://www.itu.int/pub/R-REP-BT.2408.). Basically this says that diffuse 
white should be set (table 1) at signal levels 58% and 75% for PQ and 
HLG respectively. This corresponds, for both PQ and HLG, to a display 
luminance of 203 nits (when the HLG is displayed on a 1000 nit monitor). 
Dolby, indeed their CTO Craig Todd, where involved in drafting this 
report (as were many other organisations, including the BBC), so I think 
it is fair to say that it is generally agreed. The report also 
discusses, amongst other things, tolerance to brightness shifts (section 
4.2 and, particularly, figure 2), which may be interesting.

Best regards,
Tim

Dr Tim Borer MA, MSc, PhD, CEng, MIET, SMIEEE, Fellow SMPTE
Lead Engineer
Immersive & Interactive Content
BBC Research & Development
BBC Centre House, 56 Wood Lane, London  W12 7SB

On 18/11/2017 09:24, 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
>