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

@smfr

This is a pretty substantial and breaking change, but I agree with your analysis and CSS Color 4 is certainly incorrect (it uses the Table 4 inverse OETF, but also says that rec2020 is display-referred which is inconsistent).

The ICC documentation for BT.2020 uses the 2.4 gamma and states that the color space is display referred, noting that "some implementations" use the inverse OETF.

ITU-R BT.2087-0 whimsically notes that there are two cases in 709 to 2020 conversion which give "slightly different" colors (the difference is pretty substantial, as you note):

Non-linear to linear conversion from normalized R′G′B′ colour signals E′RE′GE′B (Rec. 709) to linearly represented, normalized RGB colour signals EREGEB (Rec. 709) is accomplished by one of two equations which produce slightly different colours from each other:

Case #1: In the case where the goal is to preserve colours seen on a Rec. 709 display1 when displayed on a Rec. 2020 display2, an approximation of the electro-optical transfer function (EOTF) from Recommendation ITU-R BT.1886 (Rec. 1886) is used:
𝐸=(𝐸′)2.40,0≤𝐸′≤1

Case #2: In the case where the source is a direct camera output and the goal is to match the colours of a direct Rec. 2020 camera output, an approximation of the Rec. 709 inverse opto-electronic transfer function (OETF) is used (see Annex 2):
𝐸=(𝐸′)2,0≤𝐸′≤1

It also notes that BT.1886 uses a more complex formula which takes into account a non-zero black luminance and describes the form with L_W = 1 and L_B = 0 as an "approximated, normalized form".

If we do change the transfer function, it should continue to be defined over the extended range not just 0 to 1.

Do we know why Apple uses the γ = 1.961 form and where that figure comes from? Are they rolling in an overall system gamma for non-reference viewing conditions? It would be very useful to know where this comes from and confirmation that it is now being changed. @smfr can you shed light on this?

It doesn't help that genuine full-gamut 2020 reference displays are exotic equipment that is rarer than hen's teeth. Makes it hard to do real, live color matching comparisons.

[css-color-4] Clarify which transfer function to use for color(rec2020 ...) #5907

A 17-inch 8k led-laser backlit IPS display with 98% 2020 coverage (area in xy) exists, but not as a commercial product.

https://sid.onlinelibrary.wiley.com/doi/am-pdf/10.1002/jsid.950 (preprint, the published article is paywalled)

Clearly noticeable differences, for example here there is a ΔE2000 of 8.5 between the current and proposed transfer curves. More noticeable when components are in the 0.02 to 0.2 range.

let color2 = new Color("rec2020-gamma24", [0.4, 0.3, 0.05]);
let color3 = new Color("rec2020", [0.4, 0.3, 0.05]);

Color.deltaE(color2, color3, "2000");      // 8.51
Color.deltaE(color2, color3, "ok") * 100;  // 8.33

ITU-R BT.709 didn't define an EOTF as at the time, there was only one display technology in use - CRT.

The BT.1886 EOTF only became necessary as more display technologies came in to use. As I understand it, the gamma value (2.4) is the average value rounded for a CRT working in the HD production environment listed in BT.2035. This is defined to give an end to end system gamma of 1.2 (when combined with the curve in a BT.709 camera) which is suitable for viewing CRT luminance levels in a dim environment.

Other systems had different end to end gammas (and hence gamma offsets applied for the display) due to the different viewing environments - cinema, printed images etc.

Apple (and I think Silicon Graphics) had a non-linear LUT applied at the OS level. Charles Poynton has a section in his book about it - I'll try and find it.

As Chris L states, the inverse OETF is required mainly when combining cameras of different formats or in scientific imagery when an exact real-life colour needs to be calculated from an image. This is commonly used in live HDR production as not all specialist cameras (such as pylon cameras, stump cameras) are currently available in HDR.

For most uses, the EOTF would be used - overlaying graphics, rendering multiple images on one display etc.

For conversions, it has been common to convert all formats to a common white level. For SDR this replicates the action of the initial reference display when adjusted. For HDR it is harder, but in our conversions we have matched the diffuse white of the HDR to the SDR, whilst applying a gamma offset to maintain the artistic look between the two.

Found it: https://poynton.ca/PDFs/Mac_gamma.pdf

For conversions, it has been common to convert all formats to a common white level. For SDR this replicates the action of the initial reference display when adjusted. For HDR it is harder, but in our conversions we have matched the diffuse white of the HDR to the SDR, whilst applying a gamma offset to maintain the artistic look between the two.

Agreed. From CSS Color HDR

When § 9 Compositing SDR and HDR content, and for color space conversion, the HDR reference white for SDR content should be anchored at 203 cd/m² [Rpt_BT.2408] so that that the HDR reference white level of the inputs to compositing will end up at the HDR reference white level of the combined signal.

@simontWork

@simontWork should I interpret your response to mean that you are in favor of the proposed redefinition of the CSS rec2020 color space?

When § 9 Compositing SDR and HDR content, and for color space conversion, the HDR reference white for SDR content should be anchored at 203 cd/m² [Rpt_BT.2408] so that that the HDR reference white level of the inputs to compositing will end up at the HDR reference white level of the combined signal.

I would argue that, as HLG is relative, you can choose a value of Lw and System Gamma such that diffuse white in HDR matches the SDR format. The HLG can then be displayed at any other level (with the correct system gamma) and the shadows and midtones will match between the HDR and SDR composites. This is what we did for the Color on the Web demos (with the bonus that if you match to sRGB, the system gamma is unity and can be ignored).

@simontWork should I interpret your response to mean that you are in favor of the proposed redefinition of the CSS rec2020 color space?

It needs to be used in conjunction with BT.1886 to be a complete definition.

I think gamma 2.4 works as designed for a dim screen in a dim surround - I don't think that it follows that the same value is correct for all viewing scenarios. Certainly in HDR, both HLG and the Dolby IQ system show a need for changes for different viewing environments (screen luminance and surround). For conversions, an assumption needs to be made and that assumption should be the viewing environment listed in BT.2035.

On the 2020 gamut monitor issue, the EBU recently held a webinar with staff from UCL:
https://tech.ebu.ch/publications/presentations/2025/20250624_wcg_metamerism_webinar/why-do-people-perceive-colours-differently-on-wcg-displays

Closed by color-js/color.js#672 which updates the definition, the sample code, and also updates any examples which converted from or to rec2020.

[css-color-4] Define rec2020 color space to use 2.4 gamma #12574

I'd like to reopen this because a color expert colleague shared the following:

IMHO, this is a very weird twist on BT.1886 specification, which says that for converting scene referred data tagged with ITU Rec.2020 (which besides primaries contains OETF as a transfer function) to display referred data we should use gamma 2.4 (which is a calculated EOTF from the mentioned OETF). On Apple platforms we do it when converting the data and we don’t need a separate color space like Rec.2020 with EOTF. Seems to me that the proposed color space is a hack to help those who don’t know a difference between OETF and EOTF.

There's probably some communication problems here.

Seems to me that the proposed color space is a hack to help those who don’t know a difference between OETF and EOTF.

This is not a proposed color space, this is how an existing color space should be defined. Everything on the web is display referred. Unfortunately, we originally defined the way to convert rec2020 to srgb (et al) using the inverse-OETF, when we should have used the (BT.1886) EOTF.

My understanding is that the proposed behavior matches the macOS Tahoe behavior (macOS prior to Tahoe uses a $\gamma=1.961$ curve).

Relevant bug reports (Firefox is changing their impl to use 2.4)

as a result of

Browsers are not handling BT.2020 images correctly png#538

I wouldn't yet say that Firefox is changing to use a gamma 2.4 curve: I wrote a patch to test it out (it hasn't been reviewed or landed). If other browser vendors adopt this I would suggest that Firefox does so as well but we haven't discussed it yet.

Closed as spec is up to date with the resolution. Also color.js has shipped this for a while, with no reported breakage.

WebKit bug report: https://bugs.webkit.org/show_bug.cgi?id=316997

chromashift: model RGB colour spaces as first class values

chromashift: model RGB colour spaces as first class values (#1553)

Navigation Menu

Repository navigation

Define rec2020 color space to use 2.4 gamma #12574

4 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Define rec2020 color space to use 2.4 gamma #12574

Description

Activity

svgeesus commented on Aug 5, 2025

svgeesus commented on Aug 5, 2025

svgeesus commented on Aug 5, 2025

svgeesus commented on Aug 5, 2025

simontWork commented on Aug 7, 2025

simontWork commented on Aug 7, 2025

svgeesus commented on Aug 7, 2025

svgeesus commented on Aug 7, 2025

simontWork commented on Aug 7, 2025

simontWork commented on Aug 7, 2025

simontWork commented on Aug 7, 2025

4 remaining items

svgeesus commented on Sep 3, 2025

annevk commented on Sep 10, 2025

ccameron-chromium commented on Sep 10, 2025

svgeesus commented on Sep 10, 2025

tnikkel commented on Sep 10, 2025

svgeesus commented on Jan 22, 2026

romainmenke commented on Jun 12, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions