Browsers are not handling BT.2020 images correctly

[svgeesus]

I'm creating more Web Platform tests for the cICP chunk. These will load a PNG image into canvas and then read back the pixel values.

As part of that, I made three images, all of small MacBeth color checkers, starting with sRGB values so each patch is in gamut. I then converted those to Display P3 and to BT.2020. When correctly decoded they should all look the same. Displaying those images in browsers, it was clear that this worked for sRGB and Display P3, but for BT.2020 the images did not match (looked washed out) so the imge data was being treated as sRGB.

• Mozilla bug report
• Chromium bug report

I will add a WebKit bug report once I have tested on a mac.

Full description of how the images were built

This is a browser bug report, not a problem with the spec

Left to right: BT.2020, Display P3, sRGB

[tnikkel]

Relevant comment from the mozilla bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1987176#c4
And from the bug where I made Firefox have this behaviour: https://bugzilla.mozilla.org/show_bug.cgi?id=1951423#c8

I'm fine with whatever is decided but hopefully we can get everyone on the same page for what to do here.

cc @ccameron-chromium seems to have landed the changeset in chromium that gives this behaviour.

[svgeesus]

@tnikkel aside from the transfer function, the main reason that the bt.2020 image looks washed out is that the wrong chromaticities are being used.

[tnikkel]

@svgeesus How did you observe/confirm that the wrong chromaticities are being used? (so that I can investigate) It looked like the right values were being used from a quick skim of the code.

[svgeesus]

You see the 2020 image, on the left, as more desaturated than the other two, right? Even on an sRGB screen (the colors are all inside the sRGB gamut).

[tnikkel]

I switched Firefox to use gamma 2.4 curve for bt.2020 in a local build to test and then all 3 test images matched on my display, so I think the primaries are okay. Please correct me if I've missed something.

[svgeesus]

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

I switched Firefox to use gamma 2.4 curve for bt.2020 in a local build to test and then all 3 test images matched on my display, so I think the primaries are okay.

Having run that build (and with gfx.color_management.mode set to 1) the images all look the same. So it was indeed the gamma being wrong, not the chromaticities for rec2020.

[ProgramMax]

Quite a while ago, I was working on some video streaming. And I noticed all my BT.2020 content was too dark and some skintone hues were off.

I was able to verify that when streamed to VLC it looked correct. But when streamed in Chrome or Firefox, it was wrong. So the content seemed fine. I figured it must have been HLS.js or some code of mine. All this time, I assumed Chrome & Firefox were behaving correctly. (What are the odds that both have the same issue?) I never found the real issue.

If it was subtle, I would drop it. But it is instead problematic. The opening of Black Panther has a lot of content in dim lighting: moonlight, dim apartment. When that content is made even more dark, it is difficult to follow what's going on. Plus, the skintone hues were noticeably off.

Just now, I skipped the HLS complications and converted the content to a WebM and played it in both Chrome and VLC. And just like before, I see VLC is correct and Chrome is incorrect. I now know it cannot be the content, cannot be HLS.js or my code, and can only be Chrome itself.

Suddenly, I remembered this bug.

I'm telling you this story to convey that fixing this has a much deeper importance than a test card and PNGs. The story was harder to follow and conveyed by people who were poorly represented. The things we care about were impacted.

It sounds like FireFox and Chrome already have fixes out, which will eventually roll out to stable. Thank you for that. This means a lot.