User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; pl-PL; rv:1.9.3a5pre) Gecko/20100602 Minefield/3.7a5pre Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a5pre) Gecko/20100602 Minefield/3.7a5pre Like the title says Reproducible: Always Steps to Reproduce: Just go to this 4 sites http://www.libpng.org/pub/png/colorcube/colorcube-pngs-sRGB.html http://www.libpng.org/pub/png/colorcube/colorcube-pngs-iCCP.html http://www.libpng.org/pub/png/colorcube/colorcube-pngs-sRGB-CSS.html http://www.libpng.org/pub/png/colorcube/colorcube-pngs-iCCP-CSS.html

Isn't this just about us NOT gamma-correcting HTML and CSS colors but gamma-correcting images? That is, isn't the summary wrong?

And in particular, setting the gfx.color_management.mode preference to 1 and then restarting makes the pages render correctly, as expected. I would be surprised if we don't have a bug on enabling css/html color gamma correction already.

I didn't find dupe so I reported this ;)

Marking as dupe of bug #454688 which reports "faint differences" visible in the testsets and has been marked WONTFIX. If you see large differences, then you may be seeing some other problem and should reopen this bug with more details about what you are observing.

Not the same thing at all. Note that all the details you need are in comment 1 and comment 2, and this bug has nothing to do with imagelib.

(In reply to comment #2) > And in particular, setting the gfx.color_management.mode preference to 1 and > then restarting makes the pages render correctly, as expected. Yep, it works on this settings. Just curious why it isn't set to 1 than by default, to works properly on all images ? Some other bug or simply standard will be broken ?

> Just curious why it isn't set to 1 than by default, Because doing that is a pretty serious performance hit; big enough to not be acceptable.

bump, still UNCONFIRMED

Yes, because I'm pretty sure we _do_ have existing bugs on this... (possibly wontfix or invalid).

(In reply to comment #1) > Isn't this just about us NOT gamma-correcting HTML and CSS colors but > gamma-correcting images? That is, isn't the summary wrong? I think the design of Mozilla is to support colour management, therefore it's a bug that it doesn't with HTML and CSS colours. It's particularly stupid when you have a PNG tagged as sRGB in order that colours therein will be consistent with CSS colours (which are sRGB per spec), but they don't come out that way. See bug 460269 comment 19.

gfx.color_management.mode = 2 causes last two rows to render incorrectly here: http://libpng.org/pub/png/png-gammatest.html

Jeff do we plan to color correct HTML/CSS?

(In reply to Max Stepin from comment #11) > gfx.color_management.mode = 2 causes last two rows to render incorrectly > here: > http://libpng.org/pub/png/png-gammatest.html I have gfx.color_management.display_profile (blank) gfx.color_management.mode 2 gfx.color_management.rendering_intent 0 and all except the iCCP ones match up. I'm not sure whether this means the final paragraph of comment 10 has been fixed or there's a configuration difference somewhere along the line. (In reply to Benoit Girard (:BenWa) from comment #12) > Jeff do we plan to color correct HTML/CSS? Who is Jeff?

Jeff is the module owner of color management for Firefox. Color management for HTML/CSS is not supported. The plan is to decode HTML/CSS and images to the same colorspace in the layer tree (sRGB?) then convert from the layer colorspace to the output colorspace. But before that happens the QCMS library needs to resolve bug 679875. We're hoping to engage the community to help out with these features since we don't have anyone that is currently free to work on this,

I'm not sure what's changed since I posted comment 13, but now once again (FF 12.0) the sRGB ones (as well as the iCCP ones, but no others) are showing inconsistency.