More discussion of this from prominent web developers: https://twitter.com/SaraSoueidan/status/1154978286889570305

Comment 40 still applies. But in addition, I'd like to see a test suite produced for web browsers, specifically to evaluate color rendering. I think this is important to help us discover and understand the different renderings in browsers, but also to use for regression testing. A big part of the reluctance of changing quite literally anything, is introducing regressions. Some of the most innocuous seeming regressions can have wide ranging consequences.

The test suite should include all supported image file formats by all browsers (a superset); untagged, tagged ICCv2, tagged ICCv4, tagged ICCv4+iccMAX, tagged other (e.g. PNG has color management support that predates ICC). And then CSS, where all possible combinations of features that can affect color rendering are used, i.e. comment 42 (which bothers me that we'd expect devs to know color can blow up in different ways on different browsers for "performant" reasons; I mean, I get it, but it's still a WTF moment, like a trap door). While colors defined in HTML and colors defined in CSS should render the same, those should be tested in all possible combinations so we know if that's true or not.

Things I'd like to catch are not just for strict compliance, but also practical rendering. Sometimes strict compliance could cause a visible mismatch when two different objects are right next to each other.

Another part of the test suite is the metric. How to test? Is it just visual comparison of objects side by side? What's the reference? How do we know what's correct? What if everything is rendered wrong in exactly the same way, they'd all match, but they're all wrong - how to catch that? It's almost like we need a simple cross platform tool that displays a fixed test pattern (no html or css rendering needed, just RGB values sent through the OS specific display pipeline - using the exact same pipeline that Firefox uses; or possibly a toggle between using the same display rendering pipeline as FF, but also a path that's as direct as the platform allows that way we can discover rendering pipeline bugs or regressions).

I'd like to think some of this exists somewhere already. I'm thinking of the web equivalent of the Ghent PDF output suite (piles of PDF files testing all kinds of basic and esoteric PDF functions, for display and print, designed to expose compliance for rendering engines).

Kornel's thingie isn't extensive, but closest test suite I know of: https://kornel.ski/en/color (lacks a lot of CSS/HTML features and eg. DCF EXIF-tagged JPEGs which aren't supported anywhere AFAIK, which forces bloating pics with embedded profiles).

Sometimes strict compliance could cause a visible mismatch when two different objects are right next to each other.

In current, partial, implementations - yes. But I think strict compliance should provide consistent experience. For every possible combination of objects (incl. SVG, video, whatnot), on any possible output device (eg. wide-gamut HDR display).

This is continually frustrating to me. Every time I browse on a new profile the web is an oversaturated mess and I'm reminded that this is what we're subjecting every user on a wide gamut display to. I suspect that we are underprioritizing this, because it is not something that screams "broken" to an average user, and it might not even be something they directly notice - it's just something that generally makes the browsing experience feel unsatisfying.

(In reply to Doug Thayer [:dthayer] from comment #47)

This is continually frustrating to me. Every time I browse on a new profile the web is an oversaturated mess and I'm reminded that this is what we're subjecting every user on a wide gamut display to. I suspect that we are underprioritizing this, because it is not something that screams "broken" to an average user, and it might not even be something they directly notice - it's just something that generally makes the browsing experience feel unsatisfying.

Does setting the pref make things acceptable?

I don't notice anything as under or oversaturated or mismatched as far as colors go after setting the pref. I don't know how much that's worth, though.

And what platform/monitor do you see the badness on?

Windows 10 desktop on a Dell U2713H: Firefox (and Edge) colors noticeably oversaturated when compared to Chrome - (fixed with pref on)
OSX on 2018 MacBook Pro built-in display: Firefox still oversaturated when compared to Chrome (and Safari), but a bit less so (also fixed with pref on)
OSX on Asus MX27AQ: Firefox, Chrome, and Safari all feel oversaturated, however Firefox slightly moreso than the rest (Firefox feels best of the three with pref on)

I am terribly sorry if I will sound harsh, but couple of recent messages here made me almost cry. In the ancient times, Firefox used to be the best browser for correct colour because it had this obscure setting that made stuff look proper, now, for years, it’s been the worst.

Does setting the pref make things acceptable?

Yes. It always has. I’ve got it ON for years, so can’t judge a performance hit, but it cannot be a deal-breaker.

And what platform/monitor do you see the badness on?

Any gamut straying from sRGB. In practice: wider. The wider – the worse.

Safari (Webkit) was and is historically correct. IE/Edge converted to sRGB which is silly, but better than Firefox. Chrome (Blink) did an amazing leap and is working towards supporting intermediate, linear highbit compositioning space (through Canvas, last time I checked, but I’m not an engineer and I don’t know what I’m talking about).

Making gfx.color_management.mode = 1 the default is the least Firefox has to do. Making sure all new, swanky, webrender-whatevah things take colour management seriously is the only way forward, really.

Sorry. Without this setting Firefox is unusable on an increasing number of displays and with increasing number of artifacts to display.

try: https://treeherder.mozilla.org/#/jobs?repo=try&revision=9abea40153a340603fc91a87a2531f794189a067

We should watch telemetry closely this nightly cycle to see how much of a hit we are going to take on decode time. My last estimation was we would roughly double decode image for untagged images. However it was made slightly faster with the AVX2 work that I have done previously. There is more we can do if it turns out to be a problem. This does not enable ICCv4 which has known bugs and is not accelerated -- I began work on an SSE2 version of the current algorithm, but we need to figure out the bugs first before shipping it. See bug 1602453 for more on that topic.

Attached file Bug 455077 - Enable color management for all images, not just tagged. — Details

This patch will also color manage everything else in the browser, particularly CSS colors, right?

(I seem to recall that enabling full color management caused lots of try failures in the gradient reftests, but that was 12 years ago, so things could well have changed).

I think Cameron was looking at this last week?

https://treeherder.mozilla.org/#/jobs?repo=try&revision=0528c8a7c9c2181d7e7781a28ce2deb2e6661967 didn't look too promising, though that also enabled another pref.

That one encountered the cert expiry issue. I did another push, and here are the Talos results:

https://treeherder.mozilla.org/perf.html#/compare?originalProject=mozilla-central&newProject=try&newRevision=8486085d421e84f465800f2167eb09c8284c07d0&framework=1&selectedTimeRange=172800

(Although as Emilio mentions, that sets both gfx.color_management.mode = 1 and gfx.color_management.enablev4 = true.)

(In reply to Cameron McCormack (:heycam) from comment #59)

https://treeherder.mozilla.org/perf.html#/compare?originalProject=mozilla-central&newProject=try&newRevision=8486085d421e84f465800f2167eb09c8284c07d0&framework=1&selectedTimeRange=172800

That doesn't look too bad, fwiw.

See also [1] for some of the original context. The plugin thing is probably much less of an issue. IIRC I added a fair amount of bogus profile detection but it was by no means exhaustive. Modern displays may handle this better, but I wouldn't be surprised if we got a lot of edge-case bug reports from things looking wrong on old displays.

Most of the perf overhead was images, so off-main-thread image decoding probably made this a good bit better.

[1] https://bholley.wordpress.com/2008/09/12/so-many-colors/

(In reply to Bobby Holley (:bholley) from comment #56)

Attached file Bug 455077 - Enable color management for all images, not just tagged. — Details

This patch will also color manage everything else in the browser, particularly CSS colors, right?

Correct, I should amend the patch description. Windows hasn't finished running but I don't expect much in the way of reftest failures. The reftests currently force the setting to 2, and force it to sRGB which should produce fairly consistent results....

(In reply to Cameron McCormack (:heycam) from comment #60)

(Although as Emilio mentions, that sets both gfx.color_management.mode = 1 and gfx.color_management.enablev4 = true.)

Yes, ICCv4 will cause problems at present.

While I’m one of the many people direly waiting for proper color management setting on Firefox getting on par with other modern browsers on wide-gamut environments, I’ll have to note that there is a minor side effect of turning on the management setting manually (so that CSS colors are also contained within sRGB limits) - Copying image (pixel data) off Firefox to other applications will make the output look heavily desaturated. Easiest way to reproduce: Open any image in browser, and try either dragging the image out of browser to any other app / or choose Copy image from the context menu, paste elsewhere.

Something to mind before applying the settings wide by default.

(In reply to Hansol Kim (zvuc) from comment #65)

While I’m one of the many people direly waiting for proper color management setting on Firefox getting on par with other modern browsers on wide-gamut environments, I’ll have to note that there is a minor side effect of turning on the management setting manually (so that CSS colors are also contained within sRGB limits) - Copying image (pixel data) off Firefox to other applications will make the output look heavily desaturated. Easiest way to reproduce: Open any image in browser, and try either dragging the image out of browser to any other app / or choose Copy image from the context menu, paste elsewhere.

Something to mind before applying the settings wide by default.

Thanks for pointing this out. I filed bug 1615397 (metabug) to track a number of bugs with respect to color management, images and the clipboard. I don't think they are a significant amount of work to fix, so I will endeavour to resolve them at the same time.

Backed out for tsan failures on gfxPlatform.cpp

Backout link: https://hg.mozilla.org/integration/autoland/rev/bea95be06f3c036dc5cd449c07d7f8f88852240a
Log link: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=292367842&repo=autoland&lineNumber=1687

Also reftest failure: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=292369389&repo=autoland&lineNumber=5147

Also xpcshell failures : https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=292368917&repo=autoland&lineNumber=5374

new try: https://treeherder.mozilla.org/#/jobs?repo=try&revision=037bd506b9309d441a6969648839f682efe2369d

https://hg.mozilla.org/mozilla-central/rev/6392325ec39e

Does not seem to work as expected for me. See https://bugzilla.mozilla.org/show_bug.cgi?id=1639584

We decided to back this out in bug 1639574. It depends on work on canvas in order to reland.

I am not sure if this is fully released to this, but there is also this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1486371 It's about color management in videos.