Bug #418538 (eanble color_management by default) has been resolved FIXED; however only the "taggedonly" color_management mode has been set by default. Eventually we should enable full color management (mode 1), to apply color management to untagged elements as well.
Don't we need to move some blocks/depends from bug #418538?
I've a problem with color management turned on and don't know if it is covered by any of the existing bugs. With an older build the value of gfx.color_management.mode is set to 1. Running Firefox the warnings within the Error Console have a greenish yellow background. Even the top bar on the Wiki (http://wiki.mozilla.org/) has the same greenish background. I made a screenshot of this issue which can be found here: http://img527.imageshack.us/my.php?image=bild2xp2.png Probably the mentioned colors will appear yellow to you. That also happens for me when I move the window from my external monitor to the MacBook one. Both have different color profiles and were calibrated 3 weeks ago by a professional tool. So do we have problems when using a multi-monitor setup? Opening the above image with Firefox 3.0.4pre shows the same greenish color. But opening the Error Console and the Wiki with that build, the color is yellow. If I set gfx.color_management.mode to 2 (reset the value) it's also fine with the latest Firefox 3.1 nightly build. Is it somehow known and already covered? Or should I file a new bug on that?
see bug 450923 comment #12 It seems that some monitors ship with poor ICC profiles driver on windows.
FWIW I'm on OS X 10.5. And this thing is only visible for Firefox. Other applications with color profile support e.g. Lightroom don't suffer from that.
Henrik - We don't currently do very much to handle multiple monitors - we use whichever profile the system gives us and leave it at that. Vlad says that most apps really don't deal with this case at all, but I don't know about lightroom. The thing with the yellows turning green should not happen on a default build from trunk - since we only color correct tagged images, there should be no color correction applied to the background of the download manager.
Henrik, you mean like attachment above? The left image has colour management enabled, right does not. (In reply to comment #3)
Henrick - cl just pointed out that this sounds suspiciously like bug 439704 where we were swapping color channels on big endian platforms. Would this platform happen to be ppc?
(In reply to comment #3) > With an older build the value of gfx.color_management.mode is set to 1. I don't have a preference gfx.color_management.mode in about:config. What is this preference again? I have a vague memory of it. > Running Firefox the warnings within the Error Console have a greenish > yellow background. For me, it appears reddish yellow (manilla folder yellow) 3.03 regardless of gfx.color_management.enabled is true or false. > I made a screenshot of this issue which can be found here: > http://img527.imageshack.us/my.php?image=bild2xp2.png The profile embedded in this image is "Monitor_12.09.208_2.icc". So the CMS in FF is performing display compensation only on that display. Colors should look correct, on that display. There are some peculiarities with this profile, however: 1. The primaries are a bit odd for an external display. I'm guessing that you're using an i1 Display, or i1 Display 2 and Eye One Match. Is this MacBook using an LED backlight? If so, this colorimeter cannot correctly calibrate or profile this display. Its calibration matrix is predicated on CCFL as a backlight source, not LED. We're kinda in a bit of a train wreck with respect to these displays, as I'm unconvinced that the primaries reported by the display itself are correct either. 2. Luminance of the display is quite good, 140 cd/m^2, but I'm suspicious of this because a.) laptops normally aren't this bright; b.) the vcgt tag in the profile indicates a very aggressive and inappropriate curve has been applied to the video card look-up table to reduce the luminance of the display. Make sure you're using the latest and greatest version of the software, and start over from scratch. Make sure you're targeting an appropriate white luminance. If it's too high, you're going to kill the display luminance in a short amount of time. It's best to reduce the brightness of the display and the ambient environment, so that you have headroom to maintain consistent brightness as the display ages. For laptops, 100 cd/m^2 is OK, you may want to go a bit lower, but not lower than 80cd/m^2 for more color discerning applications. I would like to know what software application and version number made this display profile. Feel free to forward this to me off line. 3. The tone reproduction curve of the display is set to gamma 2.3. This is not ideal for an Apple display. For Apple branded displays I'd suggest you use a gamma of 1.8 just because they seem to perform better with that TRC. You could use gamma 2.2. But I would steer you away from 2.3. It's probably minor but it just makes the video LUT curves more aggressive, and losing levels as a result. 4. The display appears to be very blue in its uncalibrated state. And it's being calibrated to 5000K or D50. I'd recommend backing off on that a bit, but I don't know your particular workflow. I think 5500K would require less aggressive display correction (obviously D65 or 6500K would require even less; but again, I'm not sure of your application). > Probably the mentioned colors will appear yellow to you. That also happens for > me when I move the window from my external monitor to the MacBook one. Both > have different color profiles and were calibrated 3 weeks ago by a professional > tool. So do we have problems when using a multi-monitor setup? Unfortunately I don't think any apps get dual display color management for free, so a web site is only going to look correct on one display. By default I would expect this to be the primary display. Chris Murphy
(In reply to comment #8) > Henrik, you mean like attachment above? > > The left image has colour management enabled, right does not. Yes, that's exactly what I see with my trunk build and having set the gfx mode to 1. (In reply to comment #9) > cl just pointed out that this sounds suspiciously like bug 439704 where we were > swapping color channels on big endian platforms. Would this platform happen to > be ppc? Bobby, no I'm on Intel and don't have a PPC platform. Chris, thanks for your great comment. I'll contact you separately, so we don't spam this bug.
Component: GFX → GFX: Color Management
QA Contact: general → color-management
Target Milestone: Future → ---
BUMP... What's the status on changing "gfx.color_management.mode" to "1" (all rendered graphics) from "2" (only tagged graphics)? I'm working on gfx.color_management.mode = 1, for years and didn't have any problem with it. Also gfx.color_management.mode = "1" aligns with the interpretations of the W3C recommendations that untagged images should assumed to be in the sRGB color space. But today only Firefox doesn't use CMS for all rendered graphics. So all other page elements and untagged images are rendered on the full monitor color gamut with inaccurate and over-saturated colors, specially on wide gamut displays. image is from this site http://www.metalvortex.com/blog/2011/08/21/643.html more info here http://cameratico.com/guides/firefox-color-management/
In reply to Virtual_ManPL [:Virtual] from comment #14) > But today only Firefox doesn't use CMS for all rendered graphics. I'm not sure what other web browsers you're referring to. Safari and Chrome do not assume sRGB for untagged images, they simply send the document's RGB values through the system untransformed. Neither Chrome nor Safari even have an option equivalent to FF mode 1 whereby untagged images are assumed to be sRGB, and are transformed to Display RGB.
I'm not the specialist here, but look on attachment I added. It's from site http://www.metalvortex.com/blog/2011/08/21/643.html and only Firefox have not enabled CMS for all rendered graphics or maybe I'm wrong understand description there... ;p
The article is showing untagged images in various web browsers, with FireFox's color management enabled (mode 1) causing the woman to look sensible, while all other browsers do not color manage the untagged image and therefore she looks over saturated. The oversaturation is expected on wide gamut displays.
Ahhhh, so I understand wrongly... reading multiple times this article seems you're right! So this is another positive aspect to change "gfx.color_management.mode" to "1" :)
(In reply to Virtual_ManPL [:Virtual] from comment #18) Well, it's a bit tricky because it can't color manage plug-in content. And most plug-ins aren't color managed. Even by default Flash isn't, although there are tags to cause it to assume sRGB for its content. If FF color manages by default but Flash doesn't, then you get a discrepancy in content, that's really obvious if the content are immediately adjacent to each other. And it would lead to a lot of user confusion when they see the inevitable discrepancies between browsers. So it'd take a concerted effort of web content creator and user education to adjust expectations.
(In reply to Chris Murphy from comment #19) > (In reply to Virtual_ManPL [:Virtual] from comment #18) > > Well, it's a bit tricky because it can't color manage plug-in content. And > most plug-ins aren't color managed. Even by default Flash isn't, although > there are tags to cause it to assume sRGB for its content. If FF color > manages by default but Flash doesn't, then you get a discrepancy in content, > that's really obvious if the content are immediately adjacent to each other. This reasoning sounds a lot like that which might have inspired the old saying "the perfect is the enemy of the good".
(In reply to Chris Lawson from comment #20) More like merely a catch-22. I don't mean to indicate that mode 1 is perfection or even extreme. I actually think it's reasonable. It just comes with other consequences and I can't say how people will react to this. Without that mode, however, our display technologies continue to diverge from sRGB.
Right, that's exactly my point: there currently exists a solution that is probably good *enough* for most users and use-cases (standard image content), but that solution isn't being used because it isn't a *perfect* solution (can't handle, e.g., poorly written Flash or other plugin content). I'd be curious to know how common the situation outlined in comment 19 is. I'd also be curious to know if real-world users actually perceive having CM turned on to be a bug, but I'm guessing no one has actually done that research.
Try releasing a beta with it enabled and see what happens. Haha. I don't know if it's common for users to compare content between browsers. I suspect it's a small percentage, but it's a huge market so 1% translates into many thousands of users. If there is a way for FF to insert code into a stream of Flash content, and tie this to the color management mode, you could in effect cause all Flash content to become color managed.
5 years ago
Depends on: 1079412
5 years ago
Depends on: 569814
Summary: Enable full color_management by default → Enable full color_management by default (i.e. set gfx.color_management.mode = 1)
With regards to the dupe issue's discussion, IMO, the only hard requirement for web compat is that CSS colours and untagged images agree. Both modes 1 and 2 have this property. With wide gamut (DCI-P3 and Adobe RGB) monitors becoming more prevalent, mode 1 makes way more sense.
fully agree mode 1 does make much more sense!
A pretty widely-circulated complaint about this is in https://twitter.com/karrisaarinen/status/1000078301061300224
Depends on: 1246976
Relevant issue here: https://bugzilla.mozilla.org/show_bug.cgi?id=1250461 Setting to 1 correctly manages color as it's supposed to now. Only need to set value to 1.
Adding DevAdvocacy keyword per the link dbaron noted above. Significantly impacts designers, and looks like we're the outlier now.
The comments in this bug so far make it sound like we might not be making the right trade-off. Hi David, you're the triage owner for this component - who is the decider on color management? In bug 569814, Benoit mentions a "Jeff", probably jrmuizel?
More dev/designer discussion here too, after that initial post. https://twitter.com/SaraSoueidan/status/1000796656164630530
Wow, old bug report. Mike, seems like a web compat issue at this point. JeffM is away and color management is not actively owned. We probably need someone to see what turning on full color management does to our benchmarks these days. Need-infoing Bas for when he is back.
We also need to check what the spec says about interpolation. IIRC when I was trying to turn this on 10 years ago, it wasn't clear what should happen for gradients with color management enabled. The naive and easy thing I'd just to interpolate the corrected RGB values, which is probably what the current code does, but I have no idea if that's the correct thing.
(In reply to David Bolter [:davidb] (NeedInfo me for attention) from comment #34) > Wow, old bug report. Mike, seems like a web compat issue at this point. Unless I misunderstand, things aren't broken, just different (I guess some designers would disagree with me....) So more of an interop thing. I don't have any strong feelings on this, but generally agreeing with the majority of major browsers is a good thing.
I need to run some more tests, however as far as I can tell there is at least no considerable performance objections to enabling full color managements. Unit tests also seem to generally be green.
it is only a change of the default setting, nothing what has any impact. And all users who want to see correct colors have to manually change this setting to 1, since 10 years. Only because nobody got courage to change it to the for everyone most usable dafault value gfx.color_management.mode = "1".
Before enabling full color management, Firefox needs ICCv4 support everywhere: Mac, Windows, Linux. Linux Firefox is using qcms which does not fully support ICCv4 profiles; I suspect but don't know that the macOS version of Firefox uses ColorSync, and the Windows version of Firefox uses ICM, both of which fully support ICCv4. Either qcms needs to support ICCv4. Or Firefox needs to replace it with lcms2, which has had ICCv4 support tested in production environments for a really long time (maybe around 10 years), and also has had some display related optimizations since qcms emerged. Anyway, it's not OK in 2018 to lack support for ICCv4 profiles or treat them as if they're ICCv2 profiels. They're essentially the default everywhere. Even colord on GNOME (and other DEs) has been creating display profiles per the ICCv4 spec and file format for years now and it does this automatically, on-the-fly, at startup time, from display EDID chromaticities, even if the display is not manually calibrated/profiled by measurements.
gfx.color_management.enablev4 is false by default. That is not an acceptable default whether gfx.color_management.mode is 1 or 2 by default - but is incrementally worse if the default is changed from 2 to 1. What you have right now with enablev4 = false is some weird half assed implementation. So no matter what devs and users are going to get something most of the time they don't expect that doesn't match other platforms or browers. Just for some timing references, ICCv4 spec was finalized and published in 2001. The current version is profile format 184.108.40.206, defined in ICC.1:2010-12, which was 8 years ago. a. If qcms properly supports ICCv4 these days, then enablev4 should be set to true and mode set to 1, in the nightlies so we can find out what sorts of new bugs we come across that have been masked because of of enabledv4 = false. b. If qcms doesn't support ICCv4 still, then you need to prioritize getting v4 supported either in qcms or drop-in lcms2 before you go back to a.
Related bugs not in the dependency tree for this bug, and maybe blocking flipping the pref, eg option B in comment #40: qcms doesn't support ICC version 4 https://bugzilla.mozilla.org/show_bug.cgi?id=488800 Turn on full color management to match Chrome/IE https://bugzilla.mozilla.org/show_bug.cgi?id=999600
(In reply to Bobby Holley (:bholley) from comment #35) > We also need to check what the spec says about interpolation. IIRC when I > was trying to turn this on 10 years ago, it wasn't clear what should happen > for gradients with color management enabled. The naive and easy thing I'd > just to interpolate the corrected RGB values, which is probably what the > current code does, but I have no idea if that's the correct thing. This would almost be correct if not for gamma correction. Have a look at the CSS 'color-interpolation' property: https://www.w3.org/TR/2003/REC-SVG11-20030114/painting.html#ColorInterpolationProperty If color-interpolation is 'auto' or color-rendering is not 'optimizeQuality', you can do whatever is most performant, so interpolating corrected RGB values (i.e. in the monitor colour space) is fine. optimizeQuality looks trickier and may involve correcting the entire framebuffer as a final step. It's unclear to me how color-interpolation: sRGB is expected to treat out-of-gamut colours.
(In reply to Greg Edwards from comment #42) > It's unclear to me how color-interpolation: sRGB is expected to treat > out-of-gamut colours. Short version: Ask firstname.lastname@example.org Long version: My expectation of this section is that it's without regard to gamut. It's strictly about whether to compute blends using a linear tone curve, or the sRGB tone curve. Chromaticties don't matter. But my further my expectation is that in CSS, the color space can only ever be sRGB, I'm not aware of a way to optionally define CSS colors in something other than sRGB (I vaguely remember there was a proposal for this, but no UA's were using it, so it got dropped?).
You need to log in before you can comment on or make changes to this bug.