1987176 - update transfer function for rec2020 colorspace to be gamma 2.4

Status: NEW

(Core :: Graphics: ImageLib, defect)

Description

[chris]

Attachment: Images in rec2020(left) srgb(center) display p3(right); top row Firefox, bottom row Chrome

PNG images in the ITU BT.2020 (rec2020) colorspace, as identified by a cICP tag are displayed as if the image data was sRGB (so they look washed out).

If they are in Display P3, also identified with cICP, they display correctly.

The test images here were all converted from sRGB data originally, so this is not about out-of-gamut colors.

Full description of how these images were made is on my GitHub
https://github.com/svgeesus/PNG-CICP-tests/tree/main/workings

I have also uploaded the test images to this report. If displayed correctly they should all look identical.

Some possibilities:

• the sRGB and Display P3 images are 8 bits per component, the BT.2020 one is a 16-bit PNG
• the cICP support added in https://bugzilla.mozilla.org/show_bug.cgi?id=1862245 only added P3 support and not any others

Comment 1

[chris]

Attachment: macbeth-srgb.png

Comment 2

[chris]

Attachment: macbeth-display-p3.png

Comment 3

[chris]

Attachment: macbeth-bt2020.png

Comment 4

[Timothy Nikkel (:tnikkel)]

I think this is because of the changes in bug 1951423.

In that bug I made images using bt.709, bt.601 and bt.2020 use the srgb transfer function. I did this because 1) I was told that nobody uses the actual transfer function for bt.709, everyone just uses srgb since it's so close 2) Chrome seemed to be doing the same thing 3) we already had a video pathway that also had this specific behaviour.

You can flip the pref gfx.color_management.rec2020_gamma_as_rec709 in about:config to opt bt.2020 out of this behaviour, and gfx.color_management.rec709_gamma_as_srgb to opt both bt.709 and bt.2020 out of this behaviour.

I don't feel particularly strongly about this but whatever we do hopefully we can try to get everybody on the same page for what to do here.

Comment 5

[BugBot [:suhaib / :marco]]

Set release status flags based on info from the regressing bug 1951423

Comment 6

[chris]

I see mention of using the sRGB transfer curve for BT.2020 (which, if you plot it, is closer to a 2.2 gamma despite the 2.4 exponent, because of the offset) so this recent CSSWG issue raised by Christopher Cameron is relevant here

Define rec2020 color space to use 2.4 gamma
https://github.com/w3c/csswg-drafts/issues/12574

CSS Color 4 has been updated to use 2.4 gamma for BT.2020 following that resolution, and the 2020 test image here was created using the 2.4 gamma from BT.1886 as well.

I agree about getting everyone on the same page. Christopher Cameron notes in that CSS issue that Apple recently switched from whatever odd vlue they previously used to 2.4 gamma for BT.2020 in Safari 26.0 beta. He also states that Chrome will switch if the issue is accepted, which it recently was.

Comment 7

[BugBot [:suhaib / :marco]]

:tnikkel, since you are the author of the regressor, bug 1951423, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.

Comment 8

[Timothy Nikkel (:tnikkel)]

If I switch us to use a simple gamma 2.4 curve for bt.2020 then all three images here match on my display.

Comment 9

[Timothy Nikkel (:tnikkel)]

Updating bug title to be what I understand this to be about.

Explanation: css color 4 spec was recently updated in https://github.com/w3c/csswg-drafts/issues/12574 to say the transfer function of bt.2020 is a simple gamma 2.4 curve. Before that there were multiple different things in use. https://bugzilla.mozilla.org/show_bug.cgi?id=1951423#c6 and the issue link above in this paragraph are good explainers.

This wasn't really regressed by bug 1951423 as that just changed us from one of the transfer functions to another (neither one being gamma 2.4). But definitely related so I'll keep it linked.

Comment 10

[chris]

If I switch us to use a simple gamma 2.4 curve for bt.2020 then all three images here match on my display.

Can I see that in a Nightly build, is there a pref I can toggle to see the result? Or is that a special build?

Comment 11

[Timothy Nikkel (:tnikkel)]

(In reply to chris from comment #10)

Can I see that in a Nightly build, is there a pref I can toggle to see the result? Or is that a special build?

I queued a try build for you with this change. It will be ready in a couple of hours. When it's ready you go here

https://treeherder.mozilla.org/jobs?repo=try&revision=af787c847ea8b9361a0cf2a8983a496ead94e0f9

then click on the green B that corresponds to the platform you are interested in. When you click a panel will open on the bottom, click "Artifacts and Debugging Tools" along the top of that panel, then look for target.tar.xz or target.dmg or target.zip (linux, mac, windows) depending on the platform.

Comment 12

[Timothy Nikkel (:tnikkel)]

Attachment: WIP: Bug 1987176. Use gamma 2.4 curve as transfer function for Bt.2020.

Comment 13

[chris]

Thanks for the detailed instructions but I don't see a link to a zip, just log files.

Comment 14

[chris]

Attachment: treeherd.png

Comment 15

[Timothy Nikkel (:tnikkel)]

Sorry about that, you have to click on the B next to "Windows opt". The "Windows 11 opt" line has some other jobs that aren't the final build.

Now that I know you want Windows I can paste the link directly for you
https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/K9jIwhqqTZiLf3gfz1_Q5w/runs/0/artifacts/public/build/target.zip

Comment 16

[chris]

Thanks. Now I see different results on those three images. The display_p3 and rec2020 ones look the same, as they should, while the sRGB one is now over-saturated on my wide-gamut screen. The color_management prefs are almost the same between that build and my regular Nightly profile.

Comment 17

[chris]

Attachment: windows-opt-prefs.png

Comment 18

[chris]

Attachment: nightly_143.0a1-prefs.png

Comment 19

[Timothy Nikkel (:tnikkel)]

Hmm, I'm not sure what is going on on your system. Those prefs and the changes in the try build should not change rendering of sRGB. The rec709 pref should only change rec709 and 601. The rec2020 pref should only change rec2020. And gfx.color_management.mode should not change anything here as all the images involved as tagged with color info. (gfx.color_management.mode = 2 means only tagged images get color managed, gfx.color_management.mode = 1 means all images are color managed with untagged images assuming to be in sRGB.)

Comment 20

[chris]

It was gfx.color_management.mode. Changing it to 1, like I usually have it (in other words, conforming to CSS Color 4 on untagged images) makes all the test images display the same. Apparently "not color managed" means "assume the screen is sRGB and throw the image data there without conversion" which works badly on a wide gamut screen.

I have now updated
https://github.com/svgeesus/PNG-CICP-tests/tree/main/workings
so there are three versions of the sRGB image:

• untagged
• sRGB chunk
• cICP chunk, saying sRGB

That might be helpful for cases like this.

Comment 21

[Timothy Nikkel (:tnikkel)]

(In reply to chris from comment #20)

It was gfx.color_management.mode. Changing it to 1, like I usually have it (in other words, conforming to CSS Color 4 on untagged images) makes all the test images display the same. Apparently "not color managed" means "assume the screen is sRGB and throw the image data there without conversion" which works badly on a wide gamut screen.

Ah okay, thanks for clarifying. Yeah with gfx.color_management.mode = 2 an untagged image is just sent straight out of decode to the screen, so if the image data and the screen do not line up it will not produce great results. We are working on switching to gfx.color_management.mode = 1.

Comment 22

[chris]

Good to hear, because in Chrome and in WebKit (and Firefox on Mac, on a P3 screen, actually) all three sRGB images are treated identically. And I see image optimization advice along the lines of "no need to tag as sRGB, that is the default anyway".

Comment 23

[BugBot [:suhaib / :marco]]

Set release status flags based on info from the regressing bug 1951423