Default to consistent luminance between SDR and HDR when channel surfing

[LarsBrg]

Web interfaces are used for TV program menus.
It is important that SDR and HDR preview images, and PIP videos appear at similar lightness levels.
In particular, the mid-tones and faces need to be similar, as this is where the important colors are.
It's not important to map white to white.

If a program is available in both SDR and HDR versions, their lightness levels should appear very close, with the HDR highlights either clipped or tone mapped.

A strong imbalance in lightness levels when channel surfing can result in epileptic seizures.
Note that US has the CALM act, for keeping audio levels within range. We don't want to force a similar law for brightness levels.

This requires a default scaling between SDR and HDR spaces such that HLG 203 nits or PQ 300 nits are mapped to SDR 1.0.
The brighter HDR content can be clipped or rolled off above 80% SDR. (Many HDR to SDR transforms roll off starting around 80% -95% SDR)

HLG mapping is probably more important than PQ mapping, as broadcast users probably channel surf more than movie viewers.

[simontWork]

Agreed.

It is important that diffuse white matches for each of the candidate colour spaces.

I would like to propose that we:
a) match the diffuse white levels of the canvases when transforming to the intermediate space
b) provide a default, simple transform from both HLG and PQ to standard dynamic range extended-sRGB to use if the display is detected to be non-HDR capable.

Extended-sRGB is used as the non-HDR display may be capable of handling P3 or BT.2020 gamut and a simple matrix can be used to convert from extended-sRGB to either P3 or BT.2020.

The HLG forwards transform (HLG Signal to XYZ D65 intermediate space):

For HLG, we want to match 75% signal using a display-referred transform to Y=1.0 in the intermediate space. By choosing a value of Lw = 302 cd/m^2 for the conversion where the system gamma equals unity (and coincidentally, the diffuse white brightness matches the 80 cd/m^2 in the sRGB spec.), this is simply:

RGBint = EOTF_HLG(R'G'B'hlg, sysgamma=1.0) = invOETF_HLG(R'G'B'hlg)
RGBout = (1.0/0.265) * RGBint
XYZout = RGB2020toXYZ(RGBout)

Default, Simple Transforms for non-HDR Display

HLG Canvas to SDR extended-sRGB

For this the backwards compatibility of the HLG signal is exploited.

Therefore, the transform can simply be

if(hlg_canvas & non_HDR_display):
RGB2020int = POW(R'G'B'hlg,2.2)
RGB709int = RGB2020toRGB709(RGB2020int)
extended_sRGB_R'G'B' = POW(RGB709int, 1.0/2.2)

PQ canvas to SDR extended-sRGB

To display a PQ canvas on a non-HDR display, tone mapping is required. One basic tone-mapping that could be used as a default is the EETF given in ITU-R BT.2390-8.

extended_sRGB to Display RGB

This is probably outside of the remit of the browser code, but is simply:

target_R'G'B' = invEOTF_sRGB(RBG2020toTargetRGB(EOTF_sRGB(extended_sRGB_R'G'B')))
target_R'G'B' = clip(target_R'G'B', 0.0, 1.0) // This is optional as should be handled by display

[ccameron-chromium]

The context around this has changed a bit since the last discussion. In particular, we now have the capability to query precise display properties, which means that a web application can do its own custom tone mapping.

I'm also very particular about the fact that conversion between color spaces should be invertible (up to clamping/rounding). So if one converts an image from rec2100-hlg -> srgb -> rec2100-hlg, this "round trip" should be the identity.

Consequently, the default behavior of the browser when it is asked "draw an image/video in color space X to canvas of color space Y" should be the simplest thing possible. If an application has a specific idea of where an SDR image's white should appear in an HLG canvas, the application can do the math to make that happen. The browser should strive to make that math as simple as possible.