1939259 - Canvas ignroing formalized default color space spec and ignoring gfx.color_management.mode = 1

Status: UNCONFIRMED

(Core :: Graphics: Canvas2D, defect)

Description

[tomdav]

Steps to reproduce:

The default color space for content rendered using CanvasRenderingContext2D has historically by convention (but not by specification) been sRGB. This is now formalized by the fact that CanvasRenderingContext2DSettings specifies a default value of "srgb" for colorSpace.

I have noticed that images resize via canvas 2D experience color shifts due to two bugs. There are very similar bugs manifesting from image paste, image copy, etc. These bugs have been ignored for decades. They all result from firefox ignoring the color profile of the image and using the monitor profile instead. These are very simple bugs to fix. The monitor profile is irrelevant! Don't use it! And for the love of god nuke the default gfx.color_management.mode of 2 that assumes untagged images should default to the display's color profile. Who came up with this nonsense? No other modern browser does this. Unacceptable. And I don't want to hear how this is a dupe of some other bug that has been ignored for decades. Going on a decade of ignorance, what's the point? Just fix it already!

Actual results:

Bug #1
Actual: For canvas 2D rendering firefox defaults to the color space of the monitor instead of srgb

Bug #2:
Actual: In canvas 2D rendering firefox assumes the color profile of untagged images is the monitor profile (even when gfx.color_management.mode = 1)

Expected results:

Bug #1
Expected: The canvas 2D color space should default to srgb

Bug #2: gfx.color_management.mode set to 1
Expected: if the image colorspace is untagged, the image colorspace should be assumed to be sRGB

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Graphics: Canvas2D' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Mayank Bansal]

Thanks for reporting! To help diagnose this issue better, please can you:

1. Type "about:support" in Firefox and copy-paste its contents here
2. If this used to work in an earlier version of Firefox, please do a bisection to find the exact change that caused this (https://mozilla.github.io/mozregression/)

Comment 3

[tomdav]

After doing more tests, it appears this is actually a bug with canvas.toDataURL(), not a Canvas default color space bug or a gfx.color.management_mode bug. My apologies for the hasty initial report. It is yet another variant of the long standing color management bugs alluded to above that have never been patched. The library I was testing uses off screen canvas, so I could not actually see where the color shifts occurred, and made some incorrect assumptions in my initial report. However, this bug impacts the ability to save canvas without color shifts, and I don't see that it has been reported before. If it is a duplicate, feel free to close, but I cannot emphasize enough that the priority of this bug and related variants needs to be escalated!

Similar to the other reported variants, these color shifts manifest when the monitor profile is something other than sRGB, and/or when an image has a profile of something other than sRGB and it does not match the monitor profile. When pasting images into Firefox, it typically results in shifts to brighter more vibrant colors, and "saving as" generally results in shifts to darker more muted colors.

In this case, canvas.toDataURL() shifts colors similar to "save as". For these color shifts to occur, Firefox is either doing an unnecessary additional color space conversion (monitor color space to sRGB color space) before saving, which it shouldn't do if the image is sRGB or already converted to sRGB color space (e.g in canvas). The only other explanation I can come up with is perhaps firefox is saving the image as rendered in the monitor profile, but without tagging the color space of the monitor in the saved image.

See below for the copy/paste variant: Not the same bug, but related, ignored for 7 years, these color shift bus need to be escalated and patched! Please!

https://bugzilla.mozilla.org/show_bug.cgi?id=1431518

Comment 4

[tomdav]

Attachment: attaching about:support

As far as about:config.  I'm (In reply to Mayank Bansal from comment #2)
> Thanks for reporting! To help diagnose this issue better, please can you:
> 1. Type "about:support" in Firefox and copy-paste its contents here
> 2. If this used to work in an earlier version of Firefox, please do a bisection to find the exact change that caused this (https://mozilla.github.io/mozregression/)

Comment 5

[tomdav]

About: config attached above.

As far as #2, no this has not necessarily worked in prior versions of FF. It been an issue for some time. We resize user submitted images before upload (using canvas) to speed up uploads, and Firefox is the only browser that shifts colors during canvas resize. Also, when users paste images (to upload) we note similar color shifts in Firefox. These color management bugs pretty much have made Firefox unusable for uploads, not necessarily a huge deal considering Firefox is now only ~2% of the market. However, I use it as my primary browser so it matters so me. :) We also notice problems with untagged images being rendered improperly by Firefox, because Firefox insists on defaulting to color management mode 2. Why? No other modern browser does this and destroys the display every untagged sRGB image. C'mon, it's almost 2025! Firefox should default to color managment mode 1 and fully color manage by default. 99% of users have no clue how to change to 1, which should be the default, but I digress!

Comment 6

[tomdav]

Another point of clarification, when I referred to "save as" above I meant to say "right click" (and copy to clipboard). To the extent right clicking on an image and selecting copy does the same thing as toDataURL() this is essentially a duplicate of the following bug:

https://bugzilla.mozilla.org/show_bug.cgi?id=1431518

Comment 7

[tomdav]

Attachment: canvas_bug.jpg

Comment 8

[tomdav]

I have put together a demo to easily replicate the bug. See screen print attached above:

Steps to replicate:

1. set gfx.color_management.mode to 1 to enable full color management in Firefox (otherwise use default color management values)

2. set monitor display to a wider gamut than sRGB (ideally use a very wide gamut to magnify the issue - I selected "vibrant" (full gamut) in the attached screen print above)

3. go to https://tomdav.com/tests/canvas.html and view the demo in Firefox
   Compare the original vs. Canvas.toDataURL and Canvas. Canvas will match original colors. Canvas.toDataURL will be shifted.

4. view the demo in Chrome
   Colors will NOT be shifted!

5. change monitor gamut to sRGB and view the demo in Firefox
   Colors will not be shifted as much, but note a very subtle boost to saturation in both Canvas and Canvas.toDataURL

6. view the demo in Chrome
   There will NOT be a subtle boost to saturation in Canvas or Canvas.toDataURL

All I am doing in the demo is loading the sample (sRGB) image, drawing it on Canvas, and comparing to Canvas.toDataURL(). There should be NO color shifts AT ALL since the sample image is sRGB and (per spec) the canvas default color space is sRGB. Firefox is for whatever reason converting the color space, not only incorrectly applying the monitor profile, but can't even seem to do a simple round trip starting from sRGB and arriving back to original destination (sRGB).

TLDR, Chrome and other browsers just work. Firefox color management is foo-bar!

Comment 9

[tomdav]

Attachment: Demonstrating color shift after 10 iterations of canvas.toDataURL(), sRGB Image, monitor set to sRGB

After more tests with monitor set to sRGB and drawing sRGB image to canvas, there is no shift in color when drawing to canvas. The color shift results from canvas.toDataURL(). While the shift is subtle for a single operation, you can clearly see how it destroys the image after just a few iterations. I've updated the test page to iterate 10 times to show the result.

Only way I can avoid shifts, even in this minimum competency test with sRGB image, is to set monitor gamut to sRGB and set gfx.color_management.force_srgb to True.

Comment 10

[tomdav]

Also, I've tried other methods of extracting the image data from canvas to avoid the color shifts manifesting with canvas.toDataURL(). However, these other methods also result in color shift. Not sure why it isn't possible to extract sRGB image data from canvas, and similarly why copying non-canvas images to clipboard have similar color shifts. It almost seems as if Firefox is serving up a bastartdized screen capture with colors in the gamut of the monitor, but with no embedded profile.

Comment 11

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:lsalzman, could you have a look please?

For more information, please visit BugBot documentation.

Comment 12

[wiagn233]

I'm not sure, but the issue mentioned here might be also due to current issue? https://bugzilla.mozilla.org/show_bug.cgi?id=1834978