514932 - [10.6] Color Management Broken in Mac OS X 10.6 Snow Leopard

Status: RESOLVED FIXED

(Core :: Graphics: Color Management, defect, P2)

Description

[William Warby]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.1.2) Gecko/20090729 Firefox/3.5.2
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.1.2) Gecko/20090729 Firefox/3.5.2

Colour management in Firefox 3.5.x worked perfectly in Mac OS X 10.5.8 - after upgrading to 10.6 Snow Leopard, color-managed images appear washed out. This has been reported by several users on the Apple Discussions site but does not appear to have been reported as a bug here (at least I can't find it, apologies if this turns out to be a duplicate)

Reproducible: Always

Steps to Reproduce:
1. View any colour-managed image in Firefox running under Mac OS X 10.6 Snow Leopard
2. Compare to the same image viewed in Safari
3. Note that the colours are not the same.
Actual Results:  
Images are not colour managed

Expected Results:  
Images should be colour managed

Comment 1

[Jo Hermans]

isn't this because Snow Leopard uses a gamma correction of 2.2 ?

Comment 2

[William Warby]

From what I've read, Snow Leopard makes several changes to colour management and one of those changes is the switch to gamma 2.2. I'm no expert in colour management and colour profiles but on Mac OS X 10.5.8, Safari and Firefox rendered photos identically and on Max OS X 10.6 they do not - the look decidedly worse in Firefox than Safari. The difference is subtle - after several comparisons I have come to the conclusion that colour management is still being applied in Firefox but still looks more washed out than it should.

View this image: http://farm4.static.flickr.com/3336/3287459727_b24a8a5c9c.jpg in Firefox then in Safari. The image is distinctly more vibrant and with a greater range of tones in Safari than it is in Firefox. Look closely at the underside of the tube in the flower which is much closer to red in Safari. This is how the image should look. Every image in Firefox on my Snow Leopard Macbook suffers from this slight case of under-saturation and lack of tonal range.

Safari is rendering the images identically to Photoshop and Firefox isn't, and Safari's rendering just looks better. Therefore, somewhat unscientifically, I lay blame with Firefox.

Comment 3

[William Warby]

As a further test, see this page: http://www.gballard.net/psd/go_live_page_profile/embeddedJPEGprofiles.html

Scroll down to the image labelled "sRGB / Standard RGB 2.2 gamma". When you hover over this image in Safari, it shows the difference between the tagged (sRGB) and untagged images. You can see the image change in Safari. In Firefox, the image does not change at all, or at least not perceptibly.

Comment 4

[Lorenzo]

Exactly, it seems all images are being rendered as Untagged sRGB by Firefox, as I can see no difference between the Tagged and Untagged sRGB samples in the link posted above.

Comment 5

[Lorenzo]

(In reply to comment #4)
> Exactly, it seems all images are being rendered as Untagged sRGB by Firefox, as
> I can see no difference between the Tagged and Untagged sRGB samples in the
> link posted above.

I meant to say: "the image under sRGB / Standard RGB 2.2 gamma" not "all images".

Comment 6

[Des Lee]

Some additional info:

I am using a wide-gamut monitor (Dell something or other) and previously in 10.5, I had Firefox colour management turned on. All other bits and pieces in OSX - for example the dock etc, had bright, oversaturated reds and oranges.  But I could live with it because Firefox looked alright.

Now with Snow Leopard, all other UI elements look good, but Firefox 3.x don't seem to respond to any combination of colour management settings - I am getting the oversaturated reds just in Firefox.

Comment 7

[benedict.law]

I got the same issue with FF3.5 in OSX 10.6. I believe the problem is that FF is not able to auto detect the monitor profile and defaults back to sRGB.

I added the exact path to my monitor profile to gfx.color_management.display_profile, now I get the same behavior as before.

Since FF assumes you're using sRGB if it cannot detect the active color profile, all the behavior described by Des Lee would be expected.

untag image -> sRGB output = no change
tagged sRGB image -> sRGB output = no change
and if using a wide gamut monitor, all sRGB elements will be over saturated. 

Can you guys try to add the path of the color profile you're using to gfx.color_management.display_profile to see if it works for you?

Comment 8

[William Warby]

Benedict,

I can confirm that this fixed the problem for me and now Firefox is behaving the same as in 10.5.8 and showing colour the same as in Safari. You've definitely hit the nail on the head and confirmed the exact nature of the bug as far as I can see.

For anyone else hitting this thread, here are the instructions to test the workaround (as I had to work this out, seems I may as well post it):

1. Go to System Preferences, select Displays, and then choose the Color tab.
2. With the top profile in the list selected (Color LCD on my Macbook) press Open Profile
3. The title bar of the popup window shows the filename of your current color profile - in my case it was "Color LCD-42717C0.icc"
4. Find that file on the file system. It should be in "/Library/ColorSync/Profiles/Displays"
5. In firefox, go to about:config in the address bar (it may warn you about dragons or voiding your warranty - just say yes).
6. Search for the setting "gfx.color_management.display_profile" and double click to edit the value.
7. Enter the full path to the color profile file - in my case, "/Library/ColorSync/Profiles/Displays/Color LCD-42717C0.icc" (without quotes).
8. Restart Firefox

Comment 9

[Lorenzo]

No go for me, I'm afraid.. The colors in Firefox are still off.. The greens are shifted towards red, in my case..

Should I change the color management mode or rendering intent from the default values for this to work?

Comment 10

[benedict.law]

Lorenzo, 

Does the color shift occur in safari too? That might be an indication of a bad color profile, unrelated to FF.

Comment 11

[Lorenzo]

No, the colors are correct in Safari. And by correct I mean the same as in Photoshop.

Comment 12

[benedict.law]

Can you double check that you give Firefox the path to the right color profile? It's really strange that it is causing color shift. 

What happens if you don't put in the path? Does it still color shift?

Comment 13

[Lorenzo]

Yes, the behavior doesn't change.

I'm also using a ICC v2 profile, in case you were wondering. I read that ICC v4 profiles weren't supported and thought that was my problem. After recalibrating and creating a v2 profile I was quite disappointed to see the same color issue..

Comment 14

[Lorenzo]

I'm an idiot!

I assumed Firefox used the user folder as a base and the folder path was relative to that.. My color profile resides in my user library/colorsync/profiles folder, not in the root library/colorsync etc.. 

It's fixed for me now!

Thanks for making me double check!

Comment 15

[benedict.law]

I'm glad it worked for you! 

Now we can confirm the workaround works for everyone.

Comment 16

[William Warby]

Good to hear that everyone now agrees on the nature of the bug and the workaround for it. The bug is still marked as unconfirmed although four people have now confirmed the same issue. Although it seems there is a workaround, it's not one that most users will discover how to apply on their own so Firefox color management is effectively broken on the current release of Mac OS X. How do we get the bug confirmed and fixed for a future release?

Comment 17

[benedict.law]

I'm not sure how this works either. This is my first time on the Firefox bug tracker.

Comment 18

[philippe (part-time)]

(In reply to comment #17)
> I'm not sure how this works either. This is my first time on the Firefox bug
> tracker.
This bug is now in the correct component and the maintainer of the color management code is notified. A bit of patience please.

Comment 19

[Des Lee]

Can confirm that entering the full path now works. For me, this was:

/Users/[username]/Library/ColorSync/Profiles/profilename

I also changed color_management.mode from 2 to 1, I think this assigns my preferred profile to all images. Seems to work better for me than 2.

Can also confirm that v4 profiles do not work (had a puzzling few minutes trying to implement the suggested workaround with my profile before realising it was a v4)

Comment 20

[Jeff Muizelaar [:jrmuizel]]

CMGetDeviceProfile(cmDisplayDeviceClass,
                                     cmDefaultDeviceID,
                                     cmDefaultProfileID,
                                     &device);

returns cmDeviceNotRegistered on snow leopard and so we fail to find any profile.

Comment 21

[Jeff Muizelaar [:jrmuizel]]

It looks like we can use CMGetSystemProfile and NCMGetProfileLocation instead of CMGetDeviceProfile

Comment 22

[Jeff Muizelaar [:jrmuizel]]

Attachment: Use CMGetSystemProfile instead of CMGetDeviceProfile

In my tests CMGetSystemProfile seemed to work on snow leopard.

I'll patch through try server so that people can test it out.

Comment 23

[Jeff Muizelaar [:jrmuizel]]

If people can remove the hard coded path and try the build at https://build.mozilla.org/tryserver-builds/[e-mail]-color-snow-leopard/ to see if that fixes things that would be great.

Comment 24

[Lorenzo]

(In reply to comment #23)
> If people can remove the hard coded path and try the build at
> https://build.mozilla.org/tryserver-builds/[e-mail]-color-snow-leopard/
> to see if that fixes things that would be great.

Done and works! Thanks!

Can we expect the patch sooner than the release of 3.7?

Comment 25

[Des Lee]

That build works fine for me too.

Comment 26

[Josh Aas]

Comment on attachment 402470 [details] [diff] [review]
Use CMGetSystemProfile instead of CMGetDeviceProfile

My primary concern is the switch from a device to a system profile. I don't know the implications of this. I need to know more about that before I can review this. I think Stuart (pav) knows quite a bit about this.

Comment 27

[Jeff Muizelaar [:jrmuizel]]

Doing some research into this it looks like there can be trouble with CMGetSystemProfile as well: http://code.google.com/p/chromium/issues/detail?id=21658

Comment 28

[Jeff Muizelaar [:jrmuizel]]

It looks like another option might be to do the following:

CMGetProfileByAVID(CGMainDisplayID(), &prof);

Comment 29

[Jeff Muizelaar [:jrmuizel]]

Attachment: Use CMGetProfileByAVID() instead of CMGetDeviceProfile

I did some more research into what the right thing to do here is.

I tried some different ways of getting a profile on snow leopard, with different monitors plugged in, etc. and this method seemed to give the best results. It also mostly matches what Qt4 and Chrome do.

Josh, I'm getting you to review this again, because I have a feeling stuart won't get to it anytime soon.

Comment 30

[Jeff Muizelaar [:jrmuizel]]

http://hg.mozilla.org/mozilla-central/rev/15fc6e9d9675

Comment 31

[Jeff Muizelaar [:jrmuizel]]

It looks like this doesn't compile on OS X 10.4:

invalid static_cast from type '_CGDirectDisplayID*' to type 'CMDisplayIDType' 

This surprises me and I will investigate.

Comment 32

[Jeff Muizelaar [:jrmuizel]]

Attachment: Use reinterpret_cast<> instead of static_cast<> for OS X 10.4

On OS X 10.4 CGDirectDisplayID is of type 'struct _CGDirectDisplayID *' whereas it is of type 'uint32_t' on OS X 10.5. Therefore, we need to use reinterpret_cast instead of static_cast to cover converting from a pointer or from an integer.

The only difference from the previous patch is the use of reinterpret_cast<> instead of static_cast<>

Comment 33

[Jeff Muizelaar [:jrmuizel]]

Attachment: Use a c-style cast instaed of static_cast<> for OS X 10.4

Turns out reinterpret_cast<> doesn't work on OS X 10.5, a c-style cast should work everywhere.

Comment 34

[Joe Drew (not getting mail)]

Comment on attachment 404948 [details] [diff] [review]
Use a c-style cast instaed of static_cast<> for OS X 10.4

if you break the build you die

Comment 35

[Joe Drew (not getting mail)]

Jeff, have you landed this on 1.9.2? If so, can you mark it appropriately fixed in the status-1.9.2?

Comment 36

[Jeff Muizelaar [:jrmuizel]]

1.9.2 landing:
http://hg.mozilla.org/releases/mozilla-1.9.2/rev/2dc4be200956