[csswg-drafts] Define rec2020 color space to use 2.4 gamma (#12574)

ccameron-chromium has just created a new issue for https://github.com/w3c/csswg-drafts:

== Define rec2020 color space to use 2.4 gamma ==
TLDR: There exists a "scene referred" definition of `rec2020` (and rec709) and a "display referred" definition. The [current definition](https://www.w3.org/TR/css-color-4/#predefined-rec2020) of `rec2020` matches the inverse-OETF (scene-referred) version. I think we should use the display-referred version.

Long version:

Over in [ITU-R BT.2020](https://www.itu.int/rec/R-REC-BT.2020-2-201510-I/en), in Table 4, they list the "non-linear transfer function" as $E'= 4.5E$ if $E\leq\beta$ else $\alpha E^{0.45}-(\alpha-1)$.

This transfer function is the "opto-electronic transfer function" (OETF), which transforms "scene light from a camera" to a signal (pixel value). There is footnote (4) next to it, saying:

> In typical production practice the encoding function of image sources is adjusted so that the final picture has the desired look, as viewed on a reference monitor having the reference decoding function of Recommendation ITU-R BT.1886, in the reference viewing environment defined in Recommendation ITU-R BT.2035.

That is to say, the "electro-optical transfer function" (EOTF), which transforms a signal (pixel value) to "display light" should use 1886.

There's something similar in over in [H.273](https://www.itu.int/rec/T-REC-H.273). It defines the same OETF in the table of transfer characteristics, but in section 8.2, has the following in note 1:

> In the cases of Rec. ITU-R BT.709-6 and Rec. ITU-R BT.2020-2 (as could be indicated by TransferCharacteristics equal to 1, 6, 14 or 15), although the value is defined in terms of a reference opto-electronic transfer characteristic function, a suggested corresponding reference electro-optical transfer characteristic function for flat panel displays used in HDTV studio production has been specified in Rec. ITU-R BT.1886-0.

Over in [BT.1886](https://www.itu.int/dms_pubrec/itu-r/rec/bt/r-rec-bt.1886-0-201103-i!!pdf-e.pdf) it defines a $\gamma=2.4$ for the EOTF.

Today, nobody does what any spec says.
* Nobody uses the inverse-OETF as an OETF, because it comes out way-way-way too bright in the dark regions.
* Nobody uses $\gamma=2.4$ as the EOTF (as 1886 would tell us to do)
* Windows and Android just treat Rec709 (and Rec2020) as having an sRGB EOTF
* Apple platforms treat it as $\gamma=1.961$ EOTF

It appears that Apple is moving to $\gamma=2.4$ EOTF in the latest beta, following the 1886 recommendation. I would be okay with moving Chromium to that (first in canvas, where values can be read back, then later for `<video>` element rendering, where overlays really matter).

To that end, I think it might be best to re-define `rec2020` to use the $\gamma=2.4$ formulation. I'd also be in favor of adding a `rec709` color space that is $\gamma=2.4$ with sRGB primaries, just to be really emphatic about things.

BTW, this is what the various transfer curves look like, compared, and mapped to sRGB values.
<img width="300" alt="Image" src="https://github.com/user-attachments/assets/adbc6881-f64b-4f40-b60a-33344e0ce87d" />


Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12574 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Tuesday, 5 August 2025 01:03:58 UTC