Closed Bug 440940 Opened 16 years ago Closed 16 years ago

Setting gfx.color_management.enabled to True Results in Blue Elements Displaying as Purple

Categories

(Core :: Graphics, defect)

Product:
Core
Component:
Graphics
Platform:
All
macOS
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: bugzilla, Assigned: bholley)

References

(
URL
)

Details

Attachments

(7 files)

ICC Profile that Causes Firefox Problems
4.74 KB, application/icc
Details
ICC Profile that DOESN'T Cause Firefox Problems
4.74 KB, application/icc
Details
Lab gamut plot of two profiles and sRGB
65.75 KB, image/png
Details
Luv gamut plot of two profiles and sRGB
138.81 KB, image/png
Details
Default Profile for this Display
3.76 KB, application/icc
Details
Lab gamut plot of custom vs EDID profiles
53.83 KB, image/png
Details
Screenshots showing the different 'rendering' of 'blue' depending on the primaries used.
334.46 KB, image/jpeg
Details 
User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9) Gecko/2008061004 Firefox/3.0b1
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9) Gecko/2008061004 Firefox/3.0b1

When http://gfx.color_management.enabled is set to True, elements such as text and the background of divs that have had their color set to blue incorrectly display as a purple color. This seems only to affect blues, as other colors display correctly. This is probably a gamut clipping error as most displays and color spaces are weak in the blues. Does Firefox correctly handle reducing the color space to a smaller display gamut?



Reproducible: Always

Steps to Reproduce:
1. Set gfx.color_management.enabled to False
2. Restart Firefox
3. Run a google search
4. Note the relatively pure blue the search result links display as
5. Set gfx.color_management.enabled to True
6. Restart Firefox
7. Run a google search
8. Note how the color of the search result links has shifted dramatically towards purple 
Actual Results:  
The blue color has been shifted towards purple. If you create that same color in a color-management-aware application such as Adobe Photoshop (by extracting the hex value for the color from the CSS), the color will match Firefox when gfx.color_management.enabled is set to False, proving that the color Firefox is rendering when gfx.color_management.enabled is set to True is wrong.

Expected Results:  
Firefox should display blue colors as blue, without a shift towards purple, matching the colors rendered by color-management-aware applications such as Adobe Photoshop and Safari.

Results seen on a MacBook Pro LCD screen with a calibrated custom profile for this specific display.

In the specific example of Google, I'm talking about Unvisited links. I am aware that Visited links become purple, but that is NOT what I am talking about.

Additionally, while setting gfx.color_management.enabled to True improves the overall color accuracy of images displayed in Firefox, the blue problem also afflicts jpgs. It was just easiest to give you guys the text example since everyone should be able to see that.
Status: UNCONFIRMED → RESOLVED
Closed: 16 years ago
Resolution: --- → DUPLICATE
verified dupe.  This one does have a nice useful demo of the problem, though.  Shifting towards purple (or towards red) seems to be a general problem.  See http://www.libpng.org/pub/png/colorcube/colorcube-pngs-sRGB.html
Status: RESOLVED → VERIFIED
Are you sure this is properly a dupe of the other bug? The other bug is listed as affecting the UI elements, not page content.
It seems likely that the underlying cause is the same, even though different items are affected.
That's fine, but until someone can sort out what exactly the issue *is*, I'd rather this not be a dupe.
Status: VERIFIED → UNCONFIRMED
Resolution: DUPLICATE → ---
Blocks: 418538
I don't see this problem with links on Win XP, FF-3.0, with color_management enabled.
Could be a mac-specific thing as win and os x handle color management VERY differently at the OS level.
With respect to this bug, I am unable to reproduce on Mac OS X 10.5.3, FF3.0 final. I am wondering if this is due to a bogus display profile, rather than one based on actual display behavior (and if it is based on EDID I would consider that generally unreliable)?
Display profile is custom created for this machine. Works in ALL color-managed programs EXCEPT Firefox.

Let me try to confirm it on my other Mac and get some friends to look at this too.
(In reply to comment #2)
> verified dupe.  This one does have a nice useful demo of the problem, though. 
> Shifting towards purple (or towards red) seems to be a general problem.  See
> http://www.libpng.org/pub/png/colorcube/colorcube-pngs-sRGB.html

With FF3.0 final on OS X 10.5.3, the CSS and PNG regardless of gfx.color_management.enabled set to true or false produce identical results. In Safari 3.1.1 they are considerably different in many cases.

Strange. On the one hand it seems to be ignoring the sRGB tag in the PNGs, but the display performance is pretty poor as though it is attempting to do display compensation on all of these PNGs. If I set gfx.color_management.enabled to false and restart, the squares all look the same as before, but display performance is much much better.

If I change to a bogus profile, and set gfx.color_management.enabled to true and restart and reload this URL, now I see differentiation between the PNG and CSS, but of course the colors are all wrong. So all is not well in color management land with PNG...
I'm not talking about PNGs. I have no idea how PNGs respond. This bug was opened because of text set by CSS and jpegs.
(In reply to comment #7)
> Could be a mac-specific thing as win and os x handle color management VERY
> differently at the OS level.

 ICM and ColorSync are used to acquire the current display profile, but I'm pretty sure lcms is being used on all platforms for display compensation conversions. So there shouldn't be a difference.
(In reply to comment #11)
> I'm not talking about PNGs. I have no idea how PNGs respond.

I was replying to someone else's comment.

> This bug was
> opened because of text set by CSS and jpegs.

Yes I saw that and tested with CSS and JPEG, and my first comment, #8, is that I can't reproduce this. JPEGs with profiles embedded appear the same between Safari, Photoshop, and FF3 with cm enabled for me.

What programs other than Firefox are you not seeing this effect?

Is the display profile a v2 or v4 profile? If it is a v4 profile, can you try building a v2 profile and seeing if you get the same effect?

The profile is built by Monaco OPTIX, so I have no control over the ICC version used.

Basically, nowhere other than FF3 do I see this problem. Photoshop, Lightroom, iPhoto, Aperature, Photomatix, Safari, etc all do not shift blues to purple.

OK, testing on a second machine showed that the same problem is not happening in the same way. The colors on the second machine _are_ changing, but in a way consistent with color management turning on and off and properly doing its thing.

I'm going to try this on a virgin Firefox profile to see if I have something in my settings or extensions causing this.
OK, it's related to the specific ICC profile for this device. Copying over a different ICC profile from a different machine (generated with the same software and colorimeter) and using it as the display profile for this machine resulted in the display looking horrible but Firefox did not change the colors as color management was toggled on and off. It appears to be something in the way Firefox is doing color management isn't handling the out-of-gamut colors well. I've attached the offending ICC profile in case someone wants to look into it.
Attached a profile from a different display, created with the same software and colorimeter, that doesn't cause Firefox to shift the blues to purple.

Whatever the difference is between the two profiles is likely what's causing Firefox to have problems.
Short explanation: 

This is not the result of a bug in Firefox proper. The profile is reporting bogus behavior for the display and lcms's perceptual rendering might be flawed, resulting in the reported purple cast. I recommend closing this bug.


Long explanation:

Opening the profile that reproduces the problem shows it thinks the red primary is orange, the green primary is green-yellow and the blue primary is blue-cyan. I suspect a possible issue with lcms's perceptual rendering because based on followup to the original bug report other applications which do not use lcms are unaffected. This makes me suspicious of what other anomalies in gamut mapping may be at play between lcms and other color management engines, even if the supplied profile correctly reports the primaries of the display.

The profile that's causing problems is for a Macbook Pro which uses LED backlighting, not CCFL. This results in a unique spectral power distribution for which the colorimeter being used does not have a custom calibration matrix, therefore it's reporting incorrect XYZ values for the primaries of the display. That in turn causes a profile that does not describe actual device behavior. There currently aren't any colorimeters in the consumer market that will correctly report the XYZ values for the primaries of this display. A spectroradiometer or "emission spectrophotometer" like a colormunki or Eye One pro could do this, but at the cost in accuracy reading low luminance values.

I'm not deliberately trying to be argumentative here, but if other programs can  interpret this profile (flawed values or not) to produce color-correct results, why is it unreasonable to expect Firefox to do the same?

If this profile were producing strange results in all programs, then I would certainly understand if Firefox produced strange results as well. However, since other programs produce correct results, shouldn't Firefox do the same?

Additionally, LED backlighting is becoming more common in laptops as time goes on. You will have an ever-increasing userbase who will have problems like this.
(In reply to comment #18)
> I'm not deliberately trying to be argumentative here, but if other programs can
>  interpret this profile (flawed values or not) to produce color-correct
> results, why is it unreasonable to expect Firefox to do the same?

Because the profile is totally bogus. There is no such display with primaries as reported by the profile for your Macbook Pro. Each color engine could deal with such an extreme situation in very different ways, and there is no rational contingency for dealing with such a profile other than perhaps to reject it. And as I'm virtually certain Firefox is using lcms, that's another project. Firefox does not perform its own color management.

Now I set the supplied display profile for my Macbook pro and the same ProPhoto RGB image in Lightroom looks the same in Firefox. They're both hue shifted toward magenta, much more than they should be. One isn't more hue shifted than the other.

> 
> If this profile were producing strange results in all programs, then I would
> certainly understand if Firefox produced strange results as well. However,
> since other programs produce correct results, shouldn't Firefox do the same?

Not necessarily, see above. And the profile is bogus in any event. You're not seeing correct colors in any of your applications. You're better off in the meantime using the visual calibrator built into the OS using the expert option.

 
> Additionally, LED backlighting is becoming more common in laptops as time goes
> on. You will have an ever-increasing userbase who will have problems like this.

Yes but only for those who custom calibrate and profile with an instrument that isn't designed for the specific LED display technology being used. It's a small number of users. It's a big of a train wreck for professionals who care about color but not all market segments communicate with each other in an ideal manner. We need either accurate chromaticities reported via EDID for the display, or we need colorimeters calibrated to the particular LED phosphor set being used and that's a big challenge considering each display manufacturer and even model can have its own unique spectral behavior. It's not as simple as with CCFL, let alone compared to CRT.
(In reply to comment #19) 
> Now I set the supplied display profile for my Macbook pro and the same ProPhoto
> RGB image in Lightroom looks the same in Firefox. They're both hue shifted
> toward magenta, much more than they should be. One isn't more hue shifted than
> the other.

supplied profile = the one Ty uploaded in comment #15

Don't know if this has any bearing on your interpretation, but it turns out that the MBP that resulted in that profile does NOT have LED backlighting, it's CCFL.
In that case I'd question the accuracy of the instrument. If the instrument is an Optix, that's the likely culprit. If it's an Optix XR I'd kinda be surprised. But then I'd compare to a second Optix XR or with a spectroradiometer, and if a discrepancy is proven, I'd see if X-Rite would swap it out.

Upon closer inspection and comparison with other display profiles, the red and green primaries for your MBP aren't outlandish, but the blue one has an unexpected hue and saturation.

There still may be issues with the perceptual rendering of lcms that is exacerbating the problem, but more data is needed. Even with your profile set I get the same previews between Firefox and other applications.
Component: General → GFX: Thebes
Product: Firefox → Core
QA Contact: general → thebes
It's an Optix XR. Both of the attached profiles were generated with the same unit.
This is a 2D L*a*b* plot.

Large red gamut boundary is for sRGB.
Next largest gamut boundary is for VS20080419-1.icc, "ICC Profile that DOESN'T Cause Firefox Problems"
Smallest gamut boundary is for MBP20080419-1.icc, "ICC Profile that Causes Firefox Problems"
This is a 2D L*u*v* plot.

Large red gamut boundary is for sRGB.
Next largest gamut boundary is for VS20080419-1.icc, "ICC Profile that DOESN'T Cause Firefox Problems"
Smallest gamut boundary is for MBP20080419-1.icc, "ICC Profile that Causes Firefox Problems"
(In reply to comment #23)
> It's an Optix XR. Both of the attached profiles were generated with the same
> unit.

I'm not exactly sure what's going on because I can't reproduce either the differences you're seeing or the blue purple shift. Except for the green primary, your MBP profile is consistent with the profile I get for my MBP LED using an Optix XR. The blue primary is just whacked.

Nevertheless I do not get blue-purple shift in Firefox, and JPEGs preview the same in all applications including Firefox, using either my own Optix XR built profile, or yours.

Your two profiles describe displays with radically different behavior. Either they do in fact have radically different behavior, or some of the measurement data is flawed. This is the weakest blue primary I've seen for a supposedly normally functioning display.

It would be interesting to see the OS built profile for this display found in /Library/ColorSync/Profiles/Displays
Here is the default ICC profile for this display supplied by Apple.
Larger plot is Color LCD-4271580, "Default Profile for this Display"
Smaller plot with cyan shifted blue primary is MBP20080419-1.icc, "ICC Profile that Causes Firefox Problems"

I think something is wrong with the instrument. Apple's chromaticity information supplied by EDID will not be this far off from actual.  And as I take a look at the other profile, VS20080419-1 is describing a device with radically different primaries than sRGB. It reports the red primary as being right on the xy boundary and that's not at all llikely. Try a different instrument and see what you get.

In any event, even when I use MBP20080419-1.icc as my display profile, I get the same results in all applications. So I'm disinclined to think this is anything but a localized problem.
Yes it seems to be a localized problem, probably INVALID, but we seem to be left with the question, why does the display look OK on other color-managed programs when using the bogus color profile (comment #9)?
That's my remaining question as well. There must be some difference in the way other color-managed programs handle bizarre edge-cases or out-of-spec profiles. While I can understand that the values within my profile might not make sense, it does make me wonder how common errant profiles like this are. The Monaco Optix XR is/was a very popular colorimeter. The MacBook Pro shares display technology with many other laptops. Perhaps coming up with strange primaries is common enough that other applications have felt the need to handle the error gracefully.

I can't reproduce this with that same profile on a Powerbook (CCFL) or Macbook Pro (LED). I would suggest Ty:

1. place the offending profile in /System/Library/ColorSync/Profiles
2. create a new fresh untouched user
3.  login using that new user
4. Go to the System Preferences: Displays panel and choose the offending profile as the current display profile
4. set gfx.color_management.enabled to true in FF and restart it
5. Find a suitable test image containing blues in LR, export as JPEG as ProPhoto RGB
6. view in Firefox, adjusting scaling in both applications so they are the same

7. Repeat in the old environment

What are the results?
(In reply to comment #30)
> That's my remaining question as well. There must be some difference in the way
> other color-managed programs handle bizarre edge-cases or out-of-spec profiles.

Are those "other color-managed programs" really all using the same color-management system (not littlecms)?  When they discard an out-of-spec profile,
what do they fall back on?  sRGB?
I will try the test suggested by Chris Murphy as soon as I wrap up my other work for the day.

All the correctly functioning color-managed apps are closed-source, so I obviously have no way of telling how they're pulling it off.
(In reply to comment #30)
> That's my remaining question as well. There must be some difference in the way
> other color-managed programs handle bizarre edge-cases or out-of-spec profiles.

I'm thinking this is a user environment specific issue. I'm not able to reproduce any differences in display with those same applications with the same display profile set on two systems.

> While I can understand that the values within my profile might not make sense,
> it does make me wonder how common errant profiles like this are.

Rare, but they happen. Keep in mind most users are using EDID based profiles, not custom ones. 

But all colorimeters can sometimes just start putting out aberrant data. It's less common in the XR, I personally know of only a couple that have gone off the deep end.

> The Monaco
> Optix XR is/was a very popular colorimeter.

The Optix XR / DTP94 is the best consumer market colorimeter for CRT and CCFL LCD displays. Nevertheless it's still possible to get bad data. And both of your profiles have questionable data in them. With CRT there is less variation in the spectral behavior of the phosphors. For CCFL LCD it's greater but you usually won't get wildly unexpected data. For LED LCD all bets are off and it depends on the LED phosphors being used and everyone had different phosphors at the moment.


> The MacBook Pro shares display
> technology with many other laptops. Perhaps coming up with strange primaries is
> common enough that other applications have felt the need to handle the error
> gracefully.

It's not common enough at all to build in a contingency like this. If there are truly malformed profiles, they're rejected (usually without notice, sometimes with notice).

We need to see if anyone else can reproduce any visual difference between FF and other color managed applications using the questionable profile, and to reproduce this on Ty's machine with a clean user environment. If it happens in a new environment but no one else can reproduce it, then I'd suggest a clean install of the system and applications. If it's still reproducible I might wonder if Ty has had any kind of eye surgery and maybe is able to see wavelengths other people can't. :-D
(In reply to comment #32)
> Are those "other color-managed programs" really all using the same
> color-management system (not littlecms)? 

Lightroom and Photoshop use ACE. iPhoto uses the Apple CMM. The results between them are very similar. I don't have a lot of experience with lcms, but I have over the course of the beta thrown quite a few display profiles and source profiles at it with a wide assortment of images, synthetic and real, on several different systems, and have not experienced it producing anything other than minor differences compared to other applications.

A ProPhoto RGB image, artificially boosted in saturation is a tall order to perceptually render for a laptop display and yet I'm doing that and getting the same visual results between FF 3 final, Lightroom, Photoshop and Preview. I haven't done extensive numerical analysis but cursory analysis shows saturated blues display in FF and Photoshop to be within 1 or 2 levels, in each channel.

> When they discard an out-of-spec
> profile,
> what do they fall back on?  sRGB?

That would not be the case here. They are rejected if they don't parse correctly, not if the XYZ values are ludicrous. I have a test display profile that says the red primary has green XYZ values, the green primary has blue XYZ values, and the blue primary has red XYZ values. And the CMS will dutifully tell the display to spit out red in order to present an image full of green foliage. Photoshop has no complaints, nor Lightroom, nor Firefox.
OK, ran the test as suggested by Chris Murphy

1. the offending profile was already in /System/Library/ColorSync/Profiles
2. created a new fresh untouched user
3. Rebooted
4. logged in using that new user
5. The offending prodile was already set in System Preferences->Display->Color
6. Loaded Firefox for the first time
7. Measured a blue value
8. set gfx.color_management.enabled to true
9. Restarted Firefox
10. Loaded same image and text as step 7
11. Measured blue value
12. Observed the same ~30 point increase in red as was reported initially
OK?

What about my steps 5 and 6 having to do with taking an image from Lightroom and comparing the same image in Firefox? There's no comparison here. I'm not surprised there is a substantial change when using this profile versus not using it.
Oh, sorry. In the virgin account, the blues are still shifted red of where they should be compared to Lightroom/Photoshop when color management is enabled in Firefox. The contrast and saturation, as well as skin tones, are better/more similar when color management is enabled in Firefox. It's just that darned shift in the blues.
1.
Have you taken an image processed and exported from Lightroom, as a ProPhoto RGB JPEG, and then handed that image over to Firefox? Do they *appear* different? I cannot reproduce this on two different machines.

2.
re: Comment #36
What is the test image of? What file format? Does it have an embedded profile? What profile?

3.
re: Comment #36
Describe how you're going about step 7.
(In reply to comment #39)
> 1.
> Have you taken an image processed and exported from Lightroom, as a ProPhoto
> RGB JPEG, and then handed that image over to Firefox? Do they *appear*
> different? I cannot reproduce this on two different machines.
Yes, I have specifically done this (though I did convert to sRGB colorspace for viewing in Photoshop and for export to jpeg due to ProPhotoRGB being too large for any current output device). With color management enabled in Firefox, the overall appearance is more similar to Lightroom/Photoshop than with color management disabled. However, the reverse is true for the blues. Blues in Firefox look better/more similar to Adobe without color management enabled.

> 
> 2.
> re: Comment #36
> What is the test image of? What file format? Does it have an embedded profile?
> What profile?
It's a pic of me on the top of Spruce Knob. Pine trees, fall colors, and sky in the background, me wearing a royal blue shirt in the foreground. The image therefore is a good sample due to containing skin tones and the memory colors of sky, chlorophyl, and red/orange leaves. Additionally, the large blue shirt is a good test for this specific problem. File format is jpeg with minimum compression with embedded sRGB profile.


> 
> 3.
> re: Comment #36
> Describe how you're going about step 7
I have an application that will allow me to sample the RGB values out of VRAM for any given value on the screen, rather than what a given program thinks it is be displaying. For instance, in Firefox, if CSS called for RGB(0,0,255) text (aka #00F or "blue"), the sampler would display RGB(35,0,255), indicating the additional red.
(In reply to comment #40)

OK on item 1, please redo the test with ProPhoto RGB embedded so that there is an exactly fair comparison between the image in Lightroom and in Firefox. It's not meant to be realistic and I know it's esoteric I'm just trying to isolate. (There are real captured colors that exist in ProPhoto that can be displayed and can be printed, but are clipped in other spaces, but this is totally separate and not immediately pertinent.)

On item 2 please resave the JPEG without an embedded sRGB profile (i.e. untagged). Now compare the sRGB JPEG in Photoshop, with the untagged (but otherwise unmodified) JPEG in Firefox.

On item 3, how do these numbers compare to the same pixels measured with DigitalColor Meter?
OK, I'm willing to throw in the towel and say that something is fraked up on my end. In order to show you guys what I was talking about, I set up a screenshot. I took the mountain top image, opened the DNG in Photoshop, converted it to sRGB, then exported it to a JPEG with embedded profile. I then opened the JPEG in Firefox with color management enabled. I arranged the windows so that the image could be seen in Firefox and Photoshop at the same time. I made the screenshot. I opened the screenshot in Photoshop to crop and reduce it for posting here. At that point, the image looked exactly like what I see on my screen. I then converted the cropped/reduced screenshot to sRGB colorspace (screenshots are automatically assigned the Display colorspace in OS X). The screenshot still looked exactly like what I see on the screen. I then used Save As for Web and Devices. In the preview for SAFWAD, the difference suddenly went away. I had a blue shirt and a blue shirt. Saving the file and re-opening it in Photoshop confirmed that I had identical blue shirts in both cases.

I have NO fraking clue what's going on here but it's pretty obvious it's not limited to Firefox in scope and therefore isn't y'all's problem.





Chris Murphy, do you still want me to run those tests you requested just a moment ago?
(In reply to comment #42)
> I opened the screenshot in Photoshop to crop and reduce it for
> posting here. At that point, the image looked exactly like what I see on my
> screen. I then converted the cropped/reduced screenshot to sRGB colorspace
> (screenshots are automatically assigned the Display colorspace in OS X). The
> screenshot still looked exactly like what I see on the screen. I then used Save
> As for Web and Devices. In the preview for SAFWAD, the difference suddenly went
> away.

You're getting snagged by doing too many different things at the same time. Do not convert the screen shot or crop it, just leave it as is. And Save for Web & Devices is busted when it comes to color management anyway so I wouldn't rely on anything it had to show me.

  
> Chris Murphy, do you still want me to run those tests you requested just a
> moment ago?
 
Yes, items 1 and 2. Item 3 is more trivial.
I'm using the default profile on my MacBook and I'm able to see this issue with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9pre) Gecko/2008061004 Minefield/3.0pre ID:2008061004. So it doesn't look like something is wrong on your side Ty. I'm not really familiar with all the in-depth technical details of color management. So what is needed to drive the bug forward?

Confirming the bug meanwhile.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Hardware: Macintosh → All
Version: unspecified → Trunk
Henrik, it's not clear what you're seeing. Are you seeing blues shifting purple in Firefox? Or are you seeing differences between Firefox and other color managed applications?

For this bug to be confirmed, there needs to be differences between Firefox and other applications, not merely blues shifting purple.
> For this bug to be confirmed, there needs to be differences between Firefox and
> other applications, not merely blues shifting purple.
Except that there exists no other application that applies CM to non-image content with no specified colour profile in html documents.

Take 0066cc (which is 0,102,204 in RGB), that RGB triplet represents noticeably different colours whether it is defined in sRGB or ProPhoto. So far every browser handed over these RGB values to the graphic card which meant they were interpreted in monitor's profile colour space. Webdesigners all over the world chose 0066cc when they wanted something that looked in a typical monitor's profile colour space like the colour they wanted.

Now, Firefox assumes 0066cc (ie, 0,102,204) is defined in sRGB (I guess, correct me if I am wrong) and well, 0,102,204 in sRGB is quite a bit more magenta than sRGB in my MBP's monitor's profile colour space.

No bug here whatsoever, it is just that websites were designed against a typical monitor's profile colour space will look different when interpreted against sRGB. If the Firefox designers wanted to maintain compatibility they would have had to create another generic colour space (one representing current typical monitors) but asking Mozilla to impose a new 'standard' colour space on the world might be asking for too much.
> 0,102,204 in sRGB is quite a bit more
> magenta than sRGB in my MBP's monitor's profile colour space.
Sorry, that should have read:
"0,102,204 in sRGB is quite a bit more
 magenta than 0,102,202 in my MBP's monitor's profile colour space."
(In reply to comment #46)
> > For this bug to be confirmed, there needs to be differences between Firefox and
> > other applications, not merely blues shifting purple.
> Except that there exists no other application that applies CM to non-image
> content with no specified colour profile in html documents.

This bug is explicitly about a discrepancy between Firefox and other color managed applications. Seems to me that reproducing this needs to be established first and I've not read a clear sequence where it has been reproduced.

What I am hearing is that blues are purple. Well, fine, that might actually be normal depending on the primaries of your display compared to that of sRGB. I think first we established that there isn't some anomalous behavior between color managed applications (JPEG, PNG for example), and then once that's resolve, we can look at tests that compare JPEG and PNG to CSS within the application itself to confirm something odd isn't happening with CSS.

If we don't resolve the interapplication issue first, that does not depend anywhere near as much on the display profile as does the blue purple shift.

> Now, Firefox assumes 0066cc (ie, 0,102,204) is defined in sRGB (I guess,
> correct me if I am wrong) and well, 0,102,204 in sRGB is quite a bit more
> magenta than sRGB in my MBP's monitor's profile colour space.

That value in sRGB is 43, 7, -61. For a Macbook Pro with custom profile its: 54, 11, -47. So the CMS needs to radically alter the RGB values to maintain that same color appearance: 36, 52, 195


> No bug here whatsoever, it is just that websites were designed against a
> typical monitor's profile colour space will look different when interpreted
> against sRGB.

sRGB was the typical display, and the web world hasn't even been targeting that. Web building applications don't help them target it. And their display behavior is frequently not sRGB, and EDID often contains incorrect information so that even if color management were possible it would likely give him the wrong idea as to what was going on.

Due to multiple points of failure, there is no magic pill for finally trying to solve this problem so that hopefully it doesn't get any worse.

> If the Firefox designers wanted to maintain compatibility they
> would have had to create another generic colour space (one representing current
> typical monitors) but asking Mozilla to impose a new 'standard' colour space on
> the world might be asking for too much.

Yeah it's not going to happen in my opinion. sRGB is ubiquitously targeted by digital cameras, and the same primaries are defined in Rec. 709 for HDTV. Business projectors target it also, as do pretty much all printers on the market.

Where you will continue to see divergence from these primaries is in laptops; the low end market where people don't seem to care of sRGB is not targeted; and the very high end where people want better than sRGB beavior, pushing even beyond Adobe RGB (1998) primaries.

Designers fight color management kicking and screaming because they do not like and don't understand why we have these b.s. technology problems. They will wait until the pain is too high before they change their ways.

There are some ways around this *if* we were to flip a switch and everyone was using a web browser with the same behavior. And I'm not convinced a user accessible UI element to turn this feature on and off is a good idea. I am willing to be convinced, but I think it will only extend the 1-2 month pain period to a year or more by letting people turn it off, postpone the inevitable and make it more difficult for everyone, especially the web designer who will have all these web browsers with completely different color behavior.

Getting PARITY in color behavior among the major three web browsers I think is critically important for its success, and ideally for all of this to happen in the same approximate time frame.
> This bug is explicitly about a discrepancy between Firefox and other color
> managed applications. Seems to me that reproducing this needs to be established
> first and I've not read a clear sequence where it has been reproduced.
If this helps you, on my MBP Firefox 3, Camino 2.0a1pre, Safari, Preview and Photoshop CS3 display a blue jpeg (with embedded profile) exactly the same (see the very bottom of the attached screenshot, Camino 2.0, Safari, Preview & Photoshop).

> > Now, Firefox assumes 0066cc (ie, 0,102,204) is defined in sRGB (I guess,
> > correct me if I am wrong) and well, 0,102,204 in sRGB is quite a bit more
> > magenta than sRGB in my MBP's monitor's profile colour space.
> That value in sRGB is 43, 7, -61. For a Macbook Pro with custom profile its:
> 54, 11, -47. So the CMS needs to radically alter the RGB values to maintain
> that same color appearance: 36, 52, 195
Well, my version of Photoshop politely disagrees, see attached screenshot.

> Where you will continue to see divergence from these primaries is in laptops;
> the low end market where people don't seem to care of sRGB is not targeted; 
I have not seen any display that matched sRGB. I do not think much manufacturers anymore target sRGB (if they ever did). sRGB is more of a compromise, approximate gamut than anything that is targeted. If it fits into sRGB it will pretty much fit into most monitors.

As you can see in my screenshot(s), 'blue' in CSS is more magenta when using the sRGB primaries instead of my MBP's monitor's profile primaries. I suspect that this is a colour, where the sRGB primaries differ noticeably (and in a similar fashion) from the primaries of most monitors.
(In reply to comment #45)
> For this bug to be confirmed, there needs to be differences between Firefox and
> other applications, not merely blues shifting purple.

Sorry, I think that I was a bit too premature. Ok, that was my assumption after I run a test on my MB. Now when using my Mac Mini with 10.5.3 installed, I'm not able to see a difference between this text color when color management is enabled or not. If it's needed we have to revert the status to unconfirmed.
(In reply to comment #49)
> If this helps you, on my MBP Firefox 3, Camino 2.0a1pre, Safari, Preview and
> Photoshop CS3 display a blue jpeg (with embedded profile) exactly the same (see
> the very bottom of the attached screenshot, Camino 2.0, Safari, Preview &
> Photoshop).

If they are the same, then what is the problem? And why has this bug's status set to confirmed?


> 
> > > Now, Firefox assumes 0066cc (ie, 0,102,204) is defined in sRGB (I guess,
> > > correct me if I am wrong) and well, 0,102,204 in sRGB is quite a bit more
> > > magenta than sRGB in my MBP's monitor's profile colour space.
> > That value in sRGB is 43, 7, -61. For a Macbook Pro with custom profile its:
> > 54, 11, -47. So the CMS needs to radically alter the RGB values to maintain
> > that same color appearance: 36, 52, 195
> Well, my version of Photoshop politely disagrees, see attached screenshot.

Umm? Because you are using a different display profile than I am? The RGB values needed to preserve color appearance will need to be different for every display.


> I have not seen any display that matched sRGB. I do not think much
> manufacturers anymore target sRGB (if they ever did). sRGB is more of a
> compromise, approximate gamut than anything that is targeted. If it fits into
> sRGB it will pretty much fit into most monitors.

sRGB describe the state of affairs with CRT displays and they did largely conform to sRGB. Any specific display certainly deviated from sRGB, but not by much most of the time.

For LCD this has been a different story until maybe a few years ago, they had a much smaller gamut than sRGB. This is still the case with laptop displays and low end LCDs High-end LCDs can beat sRGB.

But the color behavior of LCD varies a lot more than ever was the case with CRT, and that's still the case today. There is no such thing as "the average LCD" display.

It's not correct to say if it fits into sRGB it will fit into most monitors. The display profile embedded in your screen shot has a substantially smaller gamut especially in blue, compared to sRGB. Your display can't reproduce quite a few blues. It's normal for sRGB blues to look more magenta than you are used to because your display's blue primary is way far away from the sRGB defined blue primary.


> As you can see in my screenshot(s), 'blue' in CSS is more magenta when using
> the sRGB primaries instead of my MBP's monitor's profile primaries. I suspect
> that this is a colour, where the sRGB primaries differ noticeably (and in a
> similar fashion) from the primaries of most monitors.

I agree with you up to the point of saying "primaries of most monitors." You can't state that. The standard deviation in primaries among LCD's in use today is so large as to make defining the behavior of "most monitors" pointless and not useful.

Were we still in the CRT days, moving to sRGB would involve trivial differences among displays. That's not the case anymore. Lots of end users will see substantial differences between color management off and on in their applications, and most of it will be noticed in blues.

Anyway, I still think this bug is mistakenly labeled as confirmed given the lack of reproducibility.
(In reply to comment #52)
> Anyway, I still think this bug is mistakenly labeled as confirmed given the
> lack of reproducibility.

Ok, so lets try to get it at least back into a reopened state.
Status: NEW → RESOLVED
Closed: 16 years ago → 16 years ago
Resolution: --- → INCOMPLETE
Status: RESOLVED → REOPENED
Resolution: INCOMPLETE → ---
Looking into it
Status: REOPENED → ASSIGNED
Assignee: nobody → bholley
Status: ASSIGNED → NEW
Status: NEW → ASSIGNED
I reproduced the issue using the attached profile in firefox. In that regard, the issue is reproducible.

However, I also got the same behavior with the display of color #6666ff in GIMP (which uses lcms) and photoshop, which (presumably) does not. As such it's safe to say that firefox is rendering things correctly according to the (wack) profile.
Status: ASSIGNED → RESOLVED
Closed: 16 years ago → 16 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: