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.
Created attachment 667627 [details] untagged 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.