1834978 - gfx.color_management.mode = 2 and ... = 1 effect is reversed

Status: ASSIGNED

(Core :: Graphics: Color Management, defect, P3)

Description

[Anton]

Attachment: IMG_20230525_113831372.jpg

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

Steps to reproduce:

Change gfx.color_management.mode and then restart a browser. Check out some webpages with tagged items:
https://cameratico.com/tools/web-browser-color-management-test/
https://webkit.org/blog-files/color-gamut/

Actual results:

If gfx.color_management.mode = 2, it overrides all elements with a color profile (attached image).
If gfx.color_management.mode = 1, a color profile is only applied to properly tagged elements (I cannot attach two images here, so here is a link: https://mega.nz/file/9gwQjbpA#zOL3TSvH30-Jm9eeE3uvhvJgc0iiSYcB5SR__7f8yVs).

gfx.color_management.mode = 2 is set by default.

(The images are not perfect, but you can easily see that in the first image all 3 comparisons are different, and in the second image only the first comparison is different).

Expected results:

According to the website below, this effect should work in reverse.
https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/3.5/ICC_color_correction_in_Firefox

Comment 1

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

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

Comment 2

[Jeff Muizelaar [:jrmuizel]]

Is this a regression?

Comment 3

[Timothy Nikkel (:tnikkel)]

I used the purposefully bad color profile https://bugzilla.mozilla.org/attachment.cgi?id=9332968 and tested a nightly from a year ago compared to a nightly from today on Windows on the page https://cameratico.com/tools/web-browser-color-management-test/

The year old nightly appeared to be the same as todays nightly.

Comment 4

[Anton]

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

Is this a regression?

If I understand your comment correctly, then no. According to the documentation and the site, it should work differently.

Comment 5

[Anton]

(In reply to Timothy Nikkel (:tnikkel) from comment #3)

I used the purposefully bad color profile https://bugzilla.mozilla.org/attachment.cgi?id=9332968 and tested a nightly from a year ago compared to a nightly from today on Windows on the page https://cameratico.com/tools/web-browser-color-management-test/

The year old nightly appeared to be the same as todays nightly.

I tried to use on my other device (laptop) the colour profile you used. The problem remains and it turns out that it is not limited to my one device. I also recorded a video.

Here is the video:
https://mega.nz/file/shYyxDBI#YM1iWocbb9TC9pI7VkZzy_vjjgdMgY3y4iR4LOZdCi4

Comment 6

[Brad Werth [:bradwerth]]

Kelsey, things look fine to me on macOS, but perhaps this is an issue with our srgb handling in Windows. Would you please take a look?

Comment 7

[[:Propheticus]]

Since you are on 113.0, could it be you're seeing the issue described in Bug 1832215 ?
Try setting gfx.color_management.native_srgb to false and restart FF. Or update FF; release is at 114.0.1 and has this set to false by default (again) for Windows clients.

Comment 8

[Anton]

(In reply to [:Propheticus] from comment #7)

Since you are on 113.0, could it be you're seeing the issue described in Bug 1832215 ?
Try setting gfx.color_management.native_srgb to false and restart FF. Or update FF; release is at 114.0.1 and has this set to false by default (again) for Windows clients.

The bug on the link you sent seems similar, but my bug still hasn't been fixed.

I upgraded to 114.0.1 and the problem is still present with default settings.
Beta version 115.0b3 also has this bug with default settings.

My workaround that I described above for this bug still works.

Comment 9

[Kelsey Gilbert [:jgilbert]]

That doc is real old, but still accurate:
https://searchfox.org/mozilla-central/source/gfx/thebes/gfxPlatform.h#81

enum class CMSMode : int32_t {
  Off = 0,         // No color management
  All = 1,         // Color manage everything
  TaggedOnly = 2,  // Color manage tagged Images Only
  AllCount = 3
};

Comment 10

[Kelsey Gilbert [:jgilbert]]

We keep chasing our tails about this. What we need is tests, in CI.

Comment 11

[wiagn233]

Same problem still exists and tested on my PC on Firefox 125.0.3(Windows x64)

Comment 12

[wiagn233]

Hello? Is anyone working on this issue?

Comment 13

[wiagn233]

(In reply to Kelsey Gilbert [:jgilbert] from comment #10)

We keep chasing our tails about this. What we need is tests, in CI.

Hello. what happened to this issue? Are you working on it?

Comment 14

[wiagn233]

I did some tests, seems gfx.color_management.mode = 2 would actually doesn't do anything to the pictures without ICC tag, while gfx.color_management.mode = 1 would treat untagged pictures as sRGB and try to convert them to match monitor ICC file.

This compare is done by comparing with Edge browser and directly get color value from screenshots.

So seems firefox is doing everything correctly, but maybe we need to change the default value of gfx.color_management.mode? As W3C determined that all untagged graphics should be assumed as sRGB, and firefox is not actually doing it by default.

Comment 15

[wiagn233]

Attachment: Bug 1834978 - Change gfx.color_management.mode default value to 1 r?gfx-reviewers,jgilbert

W3C determined that all untagged graphics should be assumed as sRGB, and
Firefox is not actually doing it by default.

gfx.color_management.mode = 2 would actually doesn't do anything to the
pictures without ICC tag, while gfx.color_management.mode = 1 would
treat untagged pictures as sRGB and try to convert them to match monitor
ICC file, so we are doing things wrong. To solve this, change default
value of gfx.color_management.mode to 1.

Signed-off-by: Shengyu Qu <[e-mail]>