[Tracking Requested - why for this release]: Some users with installed monitor/display color profiles will see incorrect (usually over-saturated) colors. ## Workaround In about:config, set `gfx.color_management.native_srgb` to `false`. ## Symptoms With the pref change, in-browser color-management is assuming a display color space of (and therefore converting to) srgb instead of the color space indicated by any color profile associated with the display. > For instance, for srgb-100%-red, if the display profile is display-p3, faithfully reproducing srgb-100%-red means giving the OS `[0.91749, 0.20029, 0.13856]`. > In this case, if we give the OS `[1.0, 0.0, 0.0]` instead, we will see a redder display-p3-100%-red. > The larger the destination gamut, the more visibly incorrect the colors will look. ## Repro We can test this on a non-wide-gamut display. 1. Install a deliberately-wrong color profile for the (primary/in-use) display. (e.g. IdentityRGB-elle-V4-g10.icc) 2. For the version of Firefox in question, start the browser. (restarting it if already running) a. Ensure that in about:support, the base64 value for CMSOutputProfile matches the base64 value for the profile from #1 (such as via https://base64.guru/converter/encode/file) 3. View an image. (e.g. 230510084955-prince-harry-230506.jpg) Colors should match e.g. Chrome. An affected version of Firefox will display (possibly wildly) different colors. ## Timeline In bug 1799258, we flipped the default for `gfx.color_management.native_srgb` from `false` to `true` on Windows. This passed code review and tests on CI. This regression appears to have been first filed in bug 1823400, which was triaged as S3. We have seen a number of likely-identical bug reports which I will dupe onto this one. ## Reach This affects users: * On Windows, and * with `gfx.color_management.native_srgb` left at default, and * a color profile installed for a display * where the profile is powerful/different-from-identity enough that it's obvious when it's skipped We are mostly looking then at graphical media creators/workers, that have wider-gamuts displays. I believe most plug-and-play users with wide-gamut displays will not install a color profile, and so would be unaffected. (Such users are used to and expect the "wrong" over-saturated colors, including in e.g. Chrome)
Bug 1832215 Comment 29 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
## Workaround In about:config, set `gfx.color_management.native_srgb` to `false`. ## Symptoms With the pref change, in-browser color-management is assuming a display color space of (and therefore converting to) srgb instead of the color space indicated by any color profile associated with the display. > For instance, for srgb-100%-red, if the display profile is display-p3, faithfully reproducing srgb-100%-red means giving the OS `[0.91749, 0.20029, 0.13856]`. > In this case, if we give the OS `[1.0, 0.0, 0.0]` instead, we will see a redder display-p3-100%-red. > The larger the destination gamut, the more visibly incorrect the colors will look. ## Repro We can test this on a non-wide-gamut display. 1. Install a deliberately-wrong color profile for the (primary/in-use) display. (e.g. IdentityRGB-elle-V4-g10.icc) 2. For the version of Firefox in question, start the browser. (restarting it if already running) a. Ensure that in about:support, the base64 value for CMSOutputProfile matches the base64 value for the profile from #1 (such as via https://base64.guru/converter/encode/file) 3. View an image. (e.g. 230510084955-prince-harry-230506.jpg) Colors should match e.g. Chrome. An affected version of Firefox will display (possibly wildly) different colors. ## Timeline In bug 1799258, we flipped the default for `gfx.color_management.native_srgb` from `false` to `true` on Windows. This passed code review and tests on CI. This regression appears to have been first filed in bug 1823400, which was triaged as S3. We have seen a number of likely-identical bug reports which I will dupe onto this one. ## Reach This affects users: * On Windows, and * with `gfx.color_management.native_srgb` left at default, and * a color profile installed for a display * where the profile is powerful/different-from-identity enough that it's obvious when it's skipped We are mostly looking then at graphical media creators/workers, that have wider-gamuts displays. I believe most plug-and-play users with wide-gamut displays will not install a color profile, and so would be unaffected. (Such users are used to and expect the "wrong" over-saturated colors, including in e.g. Chrome)