425447 - When gfx.color_management.enabled is set to true, white backgrounds are seen with a blue tint

Status: RESOLVED DUPLICATE of bug 440940

(Firefox :: General, defect)

Description

[Jeff]

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

When gfx.color_management.enabled is set to "true", if a web page has a bgcolor set to some variant of white (bgcolor="white",bgcolor="#FFFFFF", bgcolor="transparent") are seen with a blue tint.

when gfx.color_management.enabled is set to "false" this behavior can not be seen

I see this on a majority of web page, so I am not providing a specific example

Reproducible: Always

Steps to Reproduce:
1. Ensure gfx.color_management.enabled is set to "true", restart browser if nessecary
2. Visit https://bugzilla.mozilla.org/ or similar webpage that has a white background
3. Note the background color is more of a blue than a white.
4.  Switch gfx.color_management.enabled is set to "false", restart browser if nessecary
5. Visit the same web page visited in step 2, the background color should be different.



This sounds very similar to bug 227072, and many of the same issues discussed in that issue seem to be relevant to this issue

Comment 1

[Jeff]

Also note this behavior can be seen in   about:blank  so it might not be an issue that is the fault of the web designer

Comment 2

[Ria Klaassen (not reading all bugmail)]

I compared two browser windows side by side, one with gfx.color_management.enabled to "true" but I see no difference.
Tested with latest trunk, windows XP.

Comment 3

[Jeff]

Looks like I am unable to reproduce this in a 3.0 beta 4 install on another system. This might be system specific and/or fixed.  Will attempt to confirm within the week.

Comment 4

[Chris Murphy]

This bug seems to be a duplicate of 440963 and 440940.

Comment 5

[Chris Murphy]

I am able to reproduce the blue tint of this bug. The purple tint in Bug 440940.  And Bug 441239, related to JPEG and sRGB.

The problem is reproducible only when combining a custom display profile, and a JPEG (I haven't tried PNG) with an embedded sRGB profile.

1. Custom profile for MacBook Pro (LED) built with an Eye One Pro (spectroradiometer). If the OS X produced profile based on display EDID information is used, the problem is not reproducible.

2. Embedded sRGB profile from a test image saved from Photoshop CS3. If the same image, without profile embedded, is used, the problem is not reproducible.

When the problem is not reproducible, the test image displays in FireFox as the same image file views in Photoshop. When reproducible, blues are too purple, white is tinted slightly cyan.

Comment 6

[Chris Murphy]

Attachment: Macbook Pro profile based on EDID

When this profile is set as the display profile, this bug, and other bugs cited are not reproducible.

Comment 7

[Chris Murphy]

Attachment: Macbook Pro custom display profile, Eye One Pro.

If this profile is set as the current display profile, bugs are reproducible for images that have an sRGB profile embedded in them. They are NOT reproducible for images that are untagged (but are still assumed by FF to be sRGB images).

Comment 8

[Chris Murphy]

(In reply to comment #5)
> I am able to reproduce the blue tint of this bug. The purple tint in Bug
> 440940.  And Bug 441239, related to JPEG and sRGB.

Sorry, did not mean to imply that Bug 440940 is valid. But I have reproduced a purple tint associated with color management - it just happens that the purple shift of blue is normal considering sRGB blue is much more magenta, than is the blue primary of most LCD displays (especially laptop displays).

Comment 9

[Chris Murphy]

Attachment: screenshot demonstrating problem

Window on the left is untagged, and matches Photoshop with sRGB assumed as source (sRGB set as RGB Working Space).

Window on the right is the same image but has an embedded profile in the file, it is displaying incorrectly. Make special note of blue and gray balance. Gray balance is way off on the right side image.

Comment 10

[Chris Murphy]

Attachment: screenshot, sRGB vs Adobe RGB embedded

Left image has sRGB embedded, demonstrates problem (white border display light blue, colors slightly off from Photoshop in particular blues and gray balance).

Right image is the same image data but has Adobe RGB (1998) embedded in it. FireFox displays it with the exact same value as Photoshop does.

So it seems there is a problem with the use of an image with sRGB embedded in it. Will now test several other sRGB profiles and see if that reveals what's going on.

Comment 11

[Chris Murphy]

OK well this is really crazy. I have two seemingly identical (except for size) JPEGs with identical sRGB profiles embedded in them. One of them in Firefox clearly exhibits the problem. The other does not. Both were produced in Photoshop CS3. Both of them preview in Photoshop, Safari, and Omniweb exactly the same. Firefox displays them differently.

Comment 12

[Chris Murphy]

Attachment: misbehaving JPEG

This JPEG previews incorrectly in Firefox, when "Macbook Pro custom display profile, Eye One Pro" profile is set as the current display profile.

It previews correctly in all other applications, with the same display profile set.

Comment 13

[Chris Murphy]

Attachment: JPEG behaves correctly

Same embedded profile, same image file, but different compression setting. Previews fine in all applications including Firefox.

Comment 14

[Chris Murphy]

Sorry about all the posts. But I think I've figured this out, at least insofar as Firefox is concerned. Using the AppleScript "Show Profile Info", the two JPEGs I just posted have different intent flags set. The misbehaving one is set to "Absolute Colorimetric" and the behaving one is set to "Relative Colorimetric".

1. I do not have an explanation yet how it's even possible to change this flag when saving an image from Photohop. But it's something to separately investigate.

2. I suggest that FF development hardwire either relative colorimetric or perceptual rendering in *all* cases and to ignore the intent flag set in the embedded profile. Certainly absolute colorimetric is not appropriate.

Comment 15

[Bobby Holley (:bholley)]

Chris Murphy - Interesting. I just reproduced your investigation and also checked it on Safari (it seems like, at the very least, they're not respecting absolute intent flags).

However, this doesn't really relate to the current bug (I don't see any way we'd be dealing with intent flags with CSS colors). Can we separate the two issues? If you make a separate bug for the issue of intent flags (something we'll still have to discuss a bit), is everything else on this bug invalid?

Thanks for all your help.

Comment 16

[Chris Murphy]

Yeah it's taken a turn into something rather unrelated to the original bug report. I have not yet been able to reproduce "blue tint" backgrounds. There isn't enough information from the original poster to reproduce this problem.

If the original poster could provide a copy of the display profile that is set at the time the problem is reproduced, that would be useful.

Comment 17

[Bobby Holley (:bholley)]

Chris - Can you make a new bug relating to the intent flag issue (CC me and add it to the blockers for bug 418538)? I figure you're probably the best person to be listed as the reporter since you discovered the issue.

Once that's done, assuming we don't her back from Jeff I'll close this bug as a dupe of bug 440940.

Comment 18

[Jeff]

Alright, modifying my monitor color profile will fix this issue for me. 

Looks similar enough to bug 440940 to call it a dupe of that. I will add my color profile information to that bug if appropriate.

Marking as dupe of 440940.

Will allow Chis Murphy/Bobby Holley to close once intent flag bug is created.