Closed Bug 390030 Opened 14 years ago Closed 13 years ago

cms changes content colors


(Core :: GFX: Color Management, defect)

Windows XP
Not set





(Reporter: u69748, Unassigned)





(1 file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a7pre) Gecko/2007072805 Minefield/3.0a7pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a7pre) Gecko/2007072805 Minefield/3.0a7pre

When i enable cms, content colors are changed.
For example, default link color rgb(0,0,255) is changed to rgb(75,0,238).
See screen shots on

Reproducible: Always

Steps to Reproduce:
1.enable cms by setting gfx.color_management.enabled=true
2.browse any pages
Depends on: colorsync
Blocks: colorsync
No longer depends on: colorsync
Version: unspecified → Trunk
Summary: cms chnages content colors → cms changes content colors
I have added screen shot on Linux (Fedora 7) on the same PC.
In this case, color system is completely broken.
See sample 3:
have you already seen this?

"Without a properly calibrated monitor and a correct color profile, color management may actually make colors look worse."
Component: General → GFX
Product: Firefox → Core
QA Contact: general → general
Attached file testcase
Reproducible with trunk/Windows 2000.

1. setting gfx.color_management.enabled=true
2. open testcase
3. take a screenshot
4. pick up the color with graphic software. 

I have adjusted color by using the Adobe Gamma. 
If I do more adjustments, a lot of efforts, time or need the Hardware Display Calibrator.
(In reply to comment #3)
> Created an attachment (id=274620) [details]
> testcase

In CSS2.1, all RGB colors are specified in the sRGB color space.
(In CSS3, it may be specified in other than sRGB, but not yet supported by Gecko.)
So, colors must be converted if display color profile is other than sRGB.
OK. Thank you, Sakai-san.

I tried to use the sRGB color profile.
It looks good. The difference of the color is a range of error. 

Mr. EMURA, Please try the testcase after this pref. 
user_pref("gfx.color_management.enabled", true);
user_pref("gfx.color_management.display_profile", "C:\\WINDOWS\\system32\\spool\\drivers\\color\\sRGB Color Space Profile.icm");
(In reply to comment #5)
> user_pref("gfx.color_management.enabled", true);
> user_pref("gfx.color_management.display_profile",
> "C:\\WINDOWS\\system32\\spool\\drivers\\color\\sRGB Color Space Profile.icm");

OK, These prefs work good.
I'd like to add this also effects Mac OS X.  Content colour is off.  Change OS to all.

When gfx.color_management.enable=false the colours closely match Safari, when it is true they are much darker and do not look right.
Blocks: 418538
I also see dark colors on Mac. Using file:///System/Library/ColorSync/Profiles/sRGB%20Profile.icc as the gfx.color_management.display_profile value doesn't change things, nor does using AdobeRGB1998.icc or Generic RGB Profile.icc (nor does leaving the value blank). For example, #003580 becomes #00226F (measured by DigitalColor Meter RGB 8-bit hex).
It is normal for there to be a difference with color management on, and it can even be a very big difference especially on Mac OS where the display tone reproduction curve is defined by gamma 1.8 instead of 2.2 as is sRGB, and on other platforms. So images will look darker on a Mac compared to how they look without color management enabled. The original content creator would argue the images look lighter or washed out  on a Macintosh without color management enabled.

This bug seems to be a duplicate of 440963 and 440940.
That may be, but OmniWeb also offers color correction via ColorSync and doesn’t darken the colors as FF3 does. (It is possible, I suppose, that they only correct images with an embedded profile or something like that, and leave CSS colors alone.)
Omniweb does not color managed untagged content.
Simon - Safari does not do color management on CSS colors. Do you notice anything different between tagged images in the two browsers?

Chris - I agree that this is probably a dupe of bug 440940 (what has become the catch-all 'weird profiles do and should cause weird color' bug). Assuming Simon detects no difference in the images, does anyone object to closing this bug as a dupe?
Yep, the catch-all but case that crops up will likely continue to crop up for two reasons.

1. Displays routinely contain bogus EDID data, which OS X uses to build a display profile from on-the-fly and then Firefox uses automatically. This could actually be a problem for default on, but I don't have any statistical data really, to gauge how big of a problem it might be if every Mac user's web browser started to color manage all colors.

2. Display in distribution have diverged from sRGB, in particular laptop displays where the primaries are quite a departure from the sRGB primaries. People have been getting used to this, including content creators. When color management is turned on, there is an instant change rather than a gradual change. 

(If we were really clever, we might consider some algorithm to actually cause a gradual shift to "on" status over a period of time, when mozilla decides to flip the switch to on for color management by default; let it take a few week. Hmmm...)
(In reply to comment #13)
> Yep, the catch-all but case that crops up will likely continue to crop up 

Maybe we should add a paragraph to the FAQ, explaining these reasons in

Glenn - I added a comment on that article asking the contributors to include something along those lines.

Chris - I don't think the gradual shift over time is a good idea (I'd imagine it would make some users hopping mad and deluge us with misguided bugs).

If I don't hear from Simon within the next day or so I'll close this bug as a dupe.
No word from Simon. Closing Bug as dupe.
Closed: 13 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 440940
Product: Core → Core Graveyard
Component: GFX → GFX: Color Management
Product: Core Graveyard → Core
QA Contact: general → color-management
You need to log in before you can comment on or make changes to this bug.