1701760 - Request sRGB images when drawing an image in Canvas

Status: REOPENED

(Core :: Graphics: Color Management, defect)

Description

[Jeff Muizelaar [:jrmuizel]]

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.

Comment 1

[Jeff Muizelaar [:jrmuizel]]

Attachment: Bug 1701760. Request sRGB images when drawing an image in Canvas.

Comment 2

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/4ab352d967d9
Request sRGB images when drawing an image in Canvas. r=aosmond

Comment 3

[Andreea Pavel [:apavel]]

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

Comment 4

[Jeff Muizelaar [:jrmuizel]]

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

Comment 5

[Pascal Chevrel:pascalc (PTO until April 26)]

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

Comment 6

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

Attachment: Backed out changeset 4ab352d967d9 (Bug 1701760) for causing flashes duing animations (bug 1708989). r=jrmuizel

Comment 7

[Julien Cristau [:jcristau]]

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

Comment 8

[Jeff Muizelaar [:jrmuizel]]

This will need to be backed out of 90 and 91

Comment 9

[Pulsebot]

Backout by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/f4fcaad7e44a
Backed out changeset 4ab352d967d9 for causing flashes duing animations (bug 1708989). r=jrmuizel

Comment 10

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

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

Comment 11

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

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

Comment 12

[Adam Fontenot]

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!

Comment 13

[Jeff Muizelaar [:jrmuizel]]

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

Comment 14

[Kelsey Gilbert [:jgilbert]]

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

Comment 15

[Timothy Nikkel (:tnikkel)]

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

Comment 16

[Adam Fontenot]

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

Comment 17

[Jeff Muizelaar [:jrmuizel]]

I've also adjusted severity of 1797902