1952703 - Color management is completely broken when Windows ACM is enabled

Status: UNCONFIRMED

(Core :: Graphics: Color Management, defect)

Description

[wiagn233]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:136.0) Gecko/20100101 Firefox/136.0

Steps to reproduce:

When ACM is enabled, firefox will try to limit images(that is outside of sRGB range) to sRGB, causing it fail to display pictures outside of sRGB range properly.

You can check the following websites for testing:
https://cameratico.com/tools/web-browser-color-management-test/
https://webkit.org/blog-files/color-gamut/

Also, with a chromium-based browser + "Force color profile" set to scRGB linear at chrome://flags/ (this would make those browsers display correctly when ACM is enabled), you can do a compare with it.(Be aware that screenshot won't work here)

Comment 1

[i73hi64d0wr5df8pckig]

Related Chrome bug: https://issues.chromium.org/issues/328856550

Comment 2

[wiagn233]

Attachment: IMG_1245.JPG

This is a photo shot when ACM enabled + edge has switched to scRGB linear mode. The left window is edge and right window is firefox 136. It's obvious that both browsers is displaying srgb correctly, but firefox is not treating ProPhotoRGB tagged image correctly.

Comment 3

[wiagn233]

Attachment: IMG_1246.JPG

Another photo with 45 degrees rotated when shoting, to reduce Moiré pattern.

Comment 4

[Ashley Hale [:ahale]]

The simplest way to get wider color gamut on screen on Windows is to change the qCMS code to generate a fake color profile for Rec2020 and have the entirety of WebRender use that, the Windows compositor knows what to do with Rec2020 as an explicit colorspace, and that naturally grows into Rec2100 for HDR displays as those are identical colorspaces.

The drawback is that you get more gradient banding compared to sRGB because the color steps are further apart, however if you are using ACM then your display is already probably getting something extremely close to Rec2020 and this may not be a meaningful issue, and you have two extra bits of precision (30bit color vs 24bit) to deal with the slight variance in how those bands land on the stepping.

Longer term we need an HDR capable solution (and more bit depth would be nice, 24bit color is showing its age).

Comment 5

[wiagn233]

(In reply to Ashley Hale [:ahale] from comment #4)

The simplest way to get wider color gamut on screen on Windows is to change the qCMS code to generate a fake color profile for Rec2020 and have the entirety of WebRender use that, the Windows compositor knows what to do with Rec2020 as an explicit colorspace, and that naturally grows into Rec2100 for HDR displays as those are identical colorspaces.

I think scRGB color space has more wider color range than Rec. 2100? We can just convert everything into FP16 scRGB space and let compositors do the else.

The drawback is that you get more gradient banding compared to sRGB because the color steps are further apart, however if you are using ACM then your display is already probably getting something extremely close to Rec2020 and this may not be a meaningful issue, and you have two extra bits of precision (30bit color vs 24bit) to deal with the slight variance in how those bands land on the stepping.

Longer term we need an HDR capable solution (and more bit depth would be nice, 24bit color is showing its age).

Seems Firefox’s current Linux HDR video playback implementation is to use another new Wayland surface that is dedicated videos(I’m not sure about this, since I didn’t look into the code). This is a nice choice, as when color pipeline API landed to upstream kernel, compositors could make use of that to offload all video color space conversion to hardware converter.

I think we can do the same on Windows, and only use scRGB for HDR as a fallback since it would have worse performance.

Comment 6

[Ashley Hale [:ahale]]

The problem that scRGB RGBA16F addresses is blending between layers in composition inside WebRender, it's not about output formats (HDR10 as RGB10A2 pixel format has much the same performance as current BGRA8 for instance, which could be very desirable), but HDR10 is not a suitable format for blending operations (which need more than 2 bit alpha channel, and need linear math, where HDR10 is Rec2100 PQ and thus very non-linear, much like sRGB is very non-linear, and Rec2020 is very non-linear because it uses the sRGB transfer function or Rec709 transfer function).

Currently web standards expect sRGB transfer function and merely live with the reality that blending is done very wrongly with colors that have been passed through these non-linear transfer functions, so using Rec2020 or P3 would not be a meaningful change in how things render now, they just change the color primaries to achieve wider gamut without any other changes to how rendering occurs, and in the same pixel format (BGRA8) there would be some additional banding artifacts on gradients with these wider gamuts simply because color stops on gradients are further apart in larger spaces.

So adopting scRGB has the implication that blending becomes linear, which is good in many ways, but is a much larger change, and the changes to the pixel format are much of the work to do on scRGB support (e.g. SWGL has to have RGBA16F pixel format render buffers and blending ops, so that when software WebRender is used to render context menus it looks the same as hardware WebRender).

I was suggesting adopting rendering natively in Rec2020 as a stepping stone - it doesn't make anything worse than sRGB overall, and requires changes to extremely little code - the hard part is just the changes to the native OS-specific compositor implementations for WebRender to explicitly specify a colorspace on all of the surfaces and swapchains (this is particularly a problem on Windows where IDXGISurface does not have a SetColorspace method, but later versions of IDXGISwapChain do have that functionality, so migrating to using only swapchains is a challenging change to make but is certainly doable for the draw compositor and layer compositor implementations at least, so there may be some performance tradeoffs).

Ironically the Windows-specific compositor changes for scRGB may be less invasive if using an RGBA16F format (which is implicitly treated as using scRGB colorspace by the Windows compositor) works on IDXGISurface, if it does not then everything has to be an IDXGISwapChain just like for Rec2020.