This will avoid the problem in bug 1631615 where untagged images get converted to device space screwing up the colors. It will also mean that the same data shows up in canvas regardless of the display profile.

https://hg.mozilla.org/mozilla-central/rev/4ab352d967d9

I've requested this be backed out from central. Pascal, can you back it up from 89?

https://hg.mozilla.org/releases/mozilla-beta/rev/f9d7e4fe4f0b

Sebastian, Jeff, what's the status of the backout for 90/91 here? AFAICT only the backout in 89 landed.

This will need to be backed out of 90 and 91

Backout merged: https://hg.mozilla.org/mozilla-central/rev/f4fcaad7e44a

Backed out from beta: https://hg.mozilla.org/releases/mozilla-beta/rev/903bfb00beb807882a1a92edcff34d81fdc8d7cb

I have a project that utilizes a canvas and have a couple of questions about the intended implementation of this change.

1. Currently, because canvases get treated as being in the device space (and input images are converted to that space when they are added to the canvas), the end result is that color management works mostly correctly for canvases. (It's only a problem if the page then depends on the data in the Canvas having precise values, see Bug 1631615.) With this change, images added to the canvas will be sRGB instead, so untagged images will not have modified canvas data. Sounds good. But is the canvas then treated as sRGB when composited so that it will be properly color managed in the display space? Or is it unmanaged, meaning that since the data is sRGB, canvases will end up being heavily oversaturated on WCG displays?

2. Standardizing canvases on the sRGB space will amount to a regression for wide gamut image support, which as far as I know currently "just work" (because the canvas targets the display space). Furthermore, it sounds to me like this will make it harder to support HDR in canvases in the future. (I have similar concerns about inputs being converted to sRGB on macOS as in Bug 1696688, although fortunately this change hasn't been adopted for other platforms.) What's the plan in terms of future-proofing Firefox's implementation of canvases and color management more generally?

Thanks!

(In reply to Adam Fontenot from comment #12)

I have a project that utilizes a canvas and have a couple of questions about the intended implementation of this change.

1. Currently, because canvases get treated as being in the device space (and input images are converted to that space when they are added to the canvas), the end result is that color management works mostly correctly for canvases. (It's only a problem if the page then depends on the data in the Canvas having precise values, see Bug 1631615.) With this change, images added to the canvas will be sRGB instead, so untagged images will not have modified canvas data. Sounds good. But is the canvas then treated as sRGB when composited so that it will be properly color managed in the display space? Or is it unmanaged, meaning that since the data is sRGB, canvases will end up being heavily oversaturated on WCG displays?

On macOS canvas is properly color managed. On other platforms it is unmanaged and so images will end up being heavily oversaturated.

2. Standardizing canvases on the sRGB space will amount to a regression for wide gamut image support, which as far as I know currently "just work" (because the canvas targets the display space). Furthermore, it sounds to me like this will make it harder to support HDR in canvases in the future. (I have similar concerns about inputs being converted to sRGB on macOS as in Bug 1696688, although fortunately this change hasn't been adopted for other platforms.) What's the plan in terms of future-proofing Firefox's implementation of canvases and color management more generally?

Yes, this will be a regression for wide gamut image support. In the future, Firefox will properly color management sRGB canvases on other platforms and will support the colorSpace context attribute which will allow constructing a display-p3 canvas.

This blocks S2 bug 1797902.
What's the status here?

At least a fix for bug 1708989 (other than backing out this bug) is needed, which I plan to do shortly.

(In reply to Jeff Muizelaar [:jrmuizel] from comment #13)

On macOS canvas is properly color managed. On other platforms it is unmanaged and so images will end up being heavily oversaturated.

Thanks for the reply. Just my opinion - this strikes me as a very serious regression that should be reconsidered. Going from "WCG and color management mostly works on canvases" to "WCG and color management don't work at all on canvases" for both the Windows and Linux platforms purely for the sake of fixing a different bug seems like a bad move.

Given that this bug has been open almost two years, it seems fair to say that it's not really a priority. Wouldn't it make sense to delay this change until canvases can be properly tagged as sRGB and color managed, fixing that half of the problem at least? Seems to me that releasing a version of this with extremely oversaturated images on canvases is going to result in obvious, public breakage for a lot of sites that use <canvas> in Firefox.

It will be sad to (hopefully temporarily) lose WCG support, but at least that part of it will be invisible to most users.

I've also adjusted severity of 1797902