User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2a1pre) Gecko/20090608 Minefield/3.6a1pre (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2a1pre) Gecko/20090608 Minefield/3.6a1pre (.NET CLR 3.5.30729)
Bug has been discovered here: http://forums.mozillazine.org/viewtopic.php?f=23&t=1219685&st=0&sk=t&sd=a
it seems to happen on some particular monitor: dell, nec, generally good monitors and wide gamut ones
Tagged images are rendered properly on firefox 3.0.10 (with color profile support enabled), in photoshop and in other browsers (safari)
But when displayed on latest firefox 3.5beta and 3.6 builds colors get darker, oversaturated
Steps to Reproduce:
1.get a good monitor: dell, nec, wide gamut in general
3.see differences with the same image rendered with photoshop or other browsers
Images look darker, oversaturated, way too much different from the correct ones.
images should render with the same colors displayed in photoshop or other browsers that supports color profiles (for example, tweaked firefox 3.0.10 or safari)
Created attachment 382507 [details]
the original image
Created attachment 382508 [details]
the image as showed in firefox 3.0.10 (color management DISABLED)
Created attachment 382510 [details]
the image as showed in firefox 3.0.10 (color management ENABLED)
Comment on attachment 382510 [details]
the image as showed in firefox 3.0.10 (color management ENABLED)
the correct one, photoshop renders the same colors: notice the greener sea.
Created attachment 382511 [details]
the same image in firefox 3.5/3.6
Created attachment 382512 [details]
the icm color profile of my monitor.
can be useful to understand what's going on.
*** Bug 497396 has been marked as a duplicate of this bug. ***
ok, I was creating a new bug because of the wrong QA Contact, feel free to keep one of the two bugs active ;)
I've been able to reproduce a difference between qcms and lcms.
This profile has a 5 point TRC, perhaps something is going wrong in the interpolation.
If you read the full story http://forums.mozillazine.org/viewtopic.php?f=23&t=1219685&st=0&sk=t&sd=a (from page 2) you'll see other examples: lot of dell owners, nec ones, and also a HP wide gamut. So this kind of particular profiles could be used by default in different monitors.
The 5 point TRC is indeed the problem. We compute a inverse LUT with only 5 points which isn't accurate enough. Patch coming soon.
nice to hear that ;)
Created attachment 382592 [details] [diff] [review]
Always use 256 entries in the inverted lut
This patch should make things better, though perhaps not perfect.
A build with the patch should eventually show up here:
It should have a name something like:
tested the build 3.6 on windows and the bad dark colors are gone away ;)
I don't know what you mean with the words "not perfect", but now "my eyes" can see the correct colors, so I suppose it's the right way to go.
As the bug seems to affect the same qcms that comes with 3.5 isn't it a good idea to mark the bug for the 1.9.1.x also?
Created attachment 382771 [details] [diff] [review]
Use at least 256 entries, add a bunch of comments, and update to upstream qcms.
Jeff, I tried your test build and it works perfectly on my Dell S2409W! Seems you got the bug nailed.
Definitely want this for 3.5.1, not sure we need to respin the RC for this alone, though. Tagging [3.5RC2?] to catch it in case we do require a second release candidate, though.
Agree: ridealong but not reason enough to force another rev.
*** Bug 498547 has been marked as a duplicate of this bug. ***
*** Bug 497415 has been marked as a duplicate of this bug. ***
did this make it into rc2?
Sadly, it did not.
It will be in 3.5.1 for sure.
Too bad it couldn't make it in RC2 and therefore final version, even if it was wanted.
Maybe if there is an RC3(doubtful) it will make it in 3.5 final.
I heard in the meeting just now that there is an rc3, but it's only localized in the ogg/theora code, so the rest of the browser isn't going to be QAed. So I'm guessing this won't make it...
That's too bad, I doubt this patch breaks anything, it has been baking on the trunk for a little while and no issues have been discovered with it.
I've noticed this bug happens on any JPG where an ICC profile is embedded.
Oh well lets hope it does make it into RC3, crosses fingers, arms, toes and legs!!!
If not 3.5.1 it is :)
We will probably not deploy Firefox 3.5 in our labs when it's out, if it doesn't contain this bug fix. We will leave 3.0.x until a version of 3.5 with the fix it out.
As many design students that rely on accurate color correction use the labs every day.
*** Bug 500157 has been marked as a duplicate of this bug. ***
*** Bug 487840 has been marked as a duplicate of this bug. ***
*** Bug 497581 has been marked as a duplicate of this bug. ***
*** Bug 496600 has been marked as a duplicate of this bug. ***
*** Bug 501505 has been marked as a duplicate of this bug. ***
Color management worked nicely for me in Firefox 3.0 (after changing setting in about:config) using the default profile for my Dell 2407WFP-HC monitor. Images looked great in Adobe Lightroom as well (where I edited my photos), and in FastPictureViewer (the only free viewer that supports monitor color profiles). Then I upgraded to Firefox 3.5 this morning and the colors look hideous. I may downgrade to 3.0.x.
See my notes here:
(In reply to comment #33)
> Color management worked nicely for me in Firefox 3.0 (after changing setting in
> about:config) using the default profile for my Dell 2407WFP-HC monitor. Images
> looked great in Adobe Lightroom as well (where I edited my photos), and in
> FastPictureViewer (the only free viewer that supports monitor color profiles).
> Then I upgraded to Firefox 3.5 this morning and the colors look hideous. I may
> downgrade to 3.0.x.
Can you upload your monitor's color profile? Also, does a trunk nightly fix the problem for you?
Created attachment 386199 [details]
Dell 2407WFP-HC color profile
I'd rather not try the nightly trunk---this is my main machine, and I want to keep it clean and tight, which is why I waited until 3.5 came out to upgrade.
(In reply to comment #35)
> Created an attachment (id=386199) [details]
> Dell 2407WFP-HC color profile
> I'd rather not try the nightly trunk---this is my main machine, and I want to
> keep it clean and tight, which is why I waited until 3.5 came out to upgrade.
From looking at your profile, it looks like the problem should be fixed on trunk and you should see a fix in 3.5.1
The question is, when will I see 3.5.1?
( P.S. For more disgruntlement, see: http://www.modelmayhem.com/po.php?thread_id=470628 )
(In reply to comment #37)
> The question is, when will I see 3.5.1?
mid-to-late July perhaps.
The blue in the background is a div with background-color: rgb(23, 163, 219), and the arrow-images have the same rgb color-code in Photoshop. In Firefox 3.5 the colors are not the same. Is this due to the bug described here?
*** Bug 501518 has been marked as a duplicate of this bug. ***
*** Bug 501778 has been marked as a duplicate of this bug. ***
*** Bug 501856 has been marked as a duplicate of this bug. ***
I just checked with the current nightly for Firefox 3.5.1 and the issue I reported in Bug 496600 is still there. I take it the fix has not been merged yet?
Won't block on this, but I'll approve the patch.
Comment on attachment 382771 [details] [diff] [review]
Approved for 220.127.116.11. a=ss
*** Bug 503993 has been marked as a duplicate of this bug. ***
Probably related to this bug:
LaCie CRT screen on G5, calibrated with Monaco Optix XR pro.
Powerbook G4, calibrated with Monaco Optix XR pro.
Both OSX 10.4.11
On both, if I create a Table-Based (3D) profile (V2 profile as far as I know), FF3 won't use the display profile: Images are converted, but then the data is sent straight to the monitor. (causing images to be too desaturated on my laptop, while they would appear way oversaturated on a wide gamut screen)
If I use a Matrix based display profile, all is well.
Bug still present with 3.5.1 :-(, i don't understand why the bug status is "fixed" ?
It's marked as FIXED because it's fixed on trunk builds. It will probably get in the next Firefox 3.5.x release. (3.5.1 was a rush-job to address a newly found security vulnerability, so only a few other fixes were included for that release; if 3.5.1 hadn't been a quick cycle then this bug would most likely have made the cut).
*** Bug 505046 has been marked as a duplicate of this bug. ***
*** Bug 505102 has been marked as a duplicate of this bug. ***
*** Bug 505402 has been marked as a duplicate of this bug. ***
*** Bug 507687 has been marked as a duplicate of this bug. ***
Verified fixed on the 1.9.1 branch using Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:18.104.22.168) Gecko/20090729 Firefox/3.5.2. I verified using the image in the URL field with a pretty good Dell monitor.
Well if the TRC in this profile describes how the display actually behaves, that's pretty impressive. And not in a good way.
I am wondering, before filing a report, is there a reason why qcms is not using mft2, if present, instead of matrix + TRC tags? This profile contains mft2.
Firefox 3.5.2 solved the issue for me. Thanks!
(In reply to comment #39)
> The blue in the background is a div with background-color: rgb(23, 163, 219),
> and the arrow-images have the same rgb color-code in Photoshop. In Firefox 3.5
> the colors are not the same. Is this due to the bug described here?
The link to png supplied is a rendered PNG, so we can't see the separate elements. My guess is that the Photoshop elements either have an ICC profile embedded in them, which Firefox is honoring and thus color managing, where as the background is not color managed.
3,5,2 still won't play nice with my table based monitor profile.
Guess I'll keep using flock then...
(In reply to comment #59)
> 3,5,2 still won't play nice with my table based monitor profile.
> Guess I'll keep using flock then...
Strange. This bug (bug 497363) seems to indicate mft2 is not being used by qcms. Yet your experience seems to indicate it is, just not correctly. I'd file a bug and post both profiles.
Here are the profiles:
The Lut profile is not used by FF 3.5.2
FF 3.0.11, Flock 2.5.1 and Safari use it without problems.
I have a dell 2408wfp display. Using the official 2408wfp.icm color profile from dell, I had perfect colors in firefox 3.0.12.
When upgraded to firefox 3.5, after applying color management, images appeared way too dark (before applying color management, they appeared too saturated, which is normal for wide gamut). downgraded back to 3.0.12 until 3.5.2 came out, but problem still exists! sites appear much darker than they should.
If I disable color management, as mentioned - colors are way too saturated, and then take a screenshot (printscreen) and paste in photoshop, apply the icm in photoshop, and viola - perfect colors like in firefox 3.0.12.
So basically, something is significantly different with the way 3.0.12 handled colors than the way 3.5.2 handles them.
So I guess it's back to 3.0.12 for me :(
I attached the icm file for my 2408wfp.
Created attachment 392740 [details]
Color profile for Dell 2408WFP
Color profile for Dell 2408WFP
This is still not working as it should be (in Firefox 3.5.2 PC). I am using the Dell 2407WFP-HC color profile attached above, and with color management turned on, images are severely posterized (see attached files).
Created attachment 393262 [details]
Image displayed in Firefox 3.5.2, color management OFF
Created attachment 393263 [details]
Image displayed in Firefox 3.5.2, color management ON
Is anyone actually monitoring this bug page?
I ask because I see that it's marked as FIXED and RESOLVED (which it's not).
(In reply to comment #60)
> (In reply to comment #59)
> > 3,5,2 still won't play nice with my table based monitor profile.
> > Guess I'll keep using flock then...
> Strange. This bug (bug 497363) seems to indicate mft2 is not being used by
> qcms. Yet your experience seems to indicate it is, just not correctly. I'd file
> a bug and post both profiles.
qcms does not support using mft2 yet.
(In reply to comment #61)
> Here are the profiles:
> The Lut profile is not used by FF 3.5.2
> FF 3.0.11, Flock 2.5.1 and Safari use it without problems.
This is bug 509710.
Anyone else noticed this is a problem on 1.9.2?
using http://a.imagehost.org/view/0418/forest_stone_2 as the example, the image is too dark and the ground is too yellow?
Btw, when saved and opened in a program that honours the tagged profile, it appears correctly.
Created attachment 396728 [details]
DSUB and DVI profiles for my BenQ G2400WD
(In reply to comment #69)
> Anyone else noticed this is a problem on 1.9.2?
> using http://a.imagehost.org/view/0418/forest_stone_2 as the example, the image
> is too dark and the ground is too yellow?
I've filed Bug 512705 for this issue.
Using gentoo linux on amd64 arch, Firefox 3.0.2 just went stable today.
The images are too dark and too much saturated. They were great with FF 3.0
My montior is a Dell 2709W (wide gammut) calibrated using Argyll and an Eye one from gretagmacbeth.
Should'nt this bug be reopened ?
Should be reopened or clarified. Problem with LUTs maybe?
I'm using a Dell C22W (Crystal) Wide Gamut. I can't find any profile for this monitor, but I calibrated it using Huey Pro, and the resulting profile seems to be v4. I had no success with either FF 3.0.15 or 3.5.2 or 3.6beta (3.5.2 only supports v2 though).
I opened a RAW (DNG) photo in Adobe Lightroom and Photoshop CS4 on Win64, then created two JPEG, one with a sRGB embedded profile, another in Adobe RGB. All 3 of them look pretty much identical when displayed in Lightroom / Photoshop, i.e. color managed correctly. Good. Both sRGB and Adobe RGB JPEG files look oversaturated in FireFox or Safari. Ouch. If I disable color management, only the sRGB is oversaturated, the Adobe RGB looks fine, which is expected since it is sent unmanaged to my wide-gamut monitor.
My feeling is that even though FF claims to support v4 profiles, they might not be supported correctly (bugs happen, it's fine, and that's why we report them). If Lightroom or Photoshop can do it, then there is a way to do it, right? I think maybe it has to do with LUT based profiles, but I don't think Huey Pro has the flexibility to create different kind of profiles...
(In reply to comment #74)
> Should be reopened or clarified. Problem with LUTs maybe?
> I'm using a Dell C22W (Crystal) Wide Gamut. I can't find any profile for this
> monitor, but I calibrated it using Huey Pro, and the resulting profile seems to
> be v4. I had no success with either FF 3.0.15 or 3.5.2 or 3.6beta (3.5.2 only
> supports v2 though).
Upload your profile and I'll take a look.
Created attachment 409419 [details]
Color Profile for a Dell C22W Wide Gamut monitor.
Here is the profile. Thank you very much.
This is a matrix profile. It is using a small LUT for the TRC rather than a gamma function, but this is very common in v2 profiles (as well as v4 profiles). If someone has a binary editor and can change the header of the profile to state it's v2 instead of v4, then retest that might be interesting to see if it's possibly a bug in the CMM. CMM's if they don't support v4 should just refuse to use them and gracefully use an alternate (in the case of FF assume the display is sRGB).
That it's different than LR and PS implies a bug. Is this system a multiple display system, or single display system? And what is the OS?
Also, FWIW, the Huey is unlikely to make the best display profile for wide gamut displays. Right now, the industry is kinda screwed with colorimeters on the market because the colorimeter calibration matrix is targeted for CCFL backlit displays with conventional color gamuts. Either wide gamut, or going LED backlit causes problems for these colorimeters. There are only a few colorimeters that have custom calibration matrices, targeting very specific displays, that work correctly with wide gamut and/or LED backlit flat panel.
Your profile should work fine with 3.7a1pre from here:
Let me know if it doesn't.
Created attachment 409422 [details]
Dell C22W Crystall generic ICC profile
Thank you Chris. Sadly, I don't have enough ICC knowledge to change that header safely. This system is a single monitor, on Windows Vista 64 bits.
Yes, I've heard the same thing about the Huey, therefore here is the generic ICC profile for that monitor, as I downloaded it from Dell Support. Maybe it is less buggy than what my colorimeters generated.
Thank you Jeff, I will try and let you know.
Chris, Jeff, is there any chance any of those two profile would work in Firefox 3.0.x, with the old lcms manager? My experience is that my custom one does not I'm just trying to figure out if I doing something wrong here, or is the support is not there anyway in 3.0 but in 3.5's gcms, or are both those ICC profiles busted and/or just plain incompatible with 3.0?
As far as I can tell they are both fine in terms of their structure. They do report y different primaries particularly the green, which is way different.
But the key thing making me think this is just a bug is that you get the same results in LR and PS but not in FF.
Have you tried both profiles, then quit and relaunch all apps? Does the manufacturer v2 profile produce the same results in FF as in LR as in PS?
I'm afraid this didn't work.
#1 Jess: I tried Minefield 3.7a1pre, and even though color management is ON and doing something (since both the sRGB and Adobe RGB photos are displayed identically; not the case when turned OFF), the photos are definitely not displayed the way they should be on a wide gamut monitor (as I see them in LR, PS). They are over-saturated.
#2 Chris: indeed, the generic Dell C22W profile seems different, I just tried it and it looks wrong on my specific monitor (good thing I calibrated, even with a Huey Pro). It looks wrong in terms of color (seriously more redish when used in FastPictureViewer), but looks OK in term of not being over-saturated or too dark. It is definitely a V2 profile. My specific profile, generated by Huey Pro is V4, according to ICCProfileInspector. I tried both, and quit Firefox each time.
#3 Jess, Chris: considering #1 and #2, you would think that if I tell Firefox to use the generic vs. the specific profile, I would see the difference, right? But I don't, so at this point I'm questioning if I'm doing things right in FF. Do you mind double-checking with me?
gfx.color_management.display_profile = file:///C:/Windows/System32/spool/drivers/color/C22W_HDMI.ICM
gfx.color_management.enabled = true
gfx.color_management.mode = 1
In 3.5.x, 3.6.x, 3.7.x:
gfx.color_management.display_profile = file:///C:/Windows/System32/spool/drivers/color/C22W_HDMI.ICM
gfx.color_management.mode = 1
gfx.color_management.rendering_intent = 0
Is this all I need? More specifically, do you guys pull info from Vista's Color Management settings for example? In this Vista dialog, the "Devices" tab let me associate my C22 ICC Profile to my display device, and I made sure it is the same profile as gfx.color_management.display_profile. In the "Advanced Tab", in the WCS Defaults, the "Device Profile" is set to that value as well.
#4 I had a little bit more time to test a few more apps and found out that FastPictureView Pro 64 bits does the right thing too. So far:
ACDSee Pro 3 & IrfanView 4.25 + plugins: claim to support color management, similar options as FF (turn management on/off, point to custom profile), but same problem on my WG monitor (over-saturated). Irfan View is especially slow with color management on.
LR 2.5, LR3, PS CS4, FastPictureView Pro 64 bits: claim to support color management, and display correctly on my WG monitor.
* FastPictureViewer seems to support v2, v4 and wcs profiles, and is surprisingly fast. I can pick either the generic or the specific C22W profile, and notice the difference immediately
* LR 2.5, LR3: you can't explicitly point to a profile, so I assume the one in Vista Color Settings is picked.
I don't know how to use gfx.color_management.display_profile so I've never used it. FF is grabbing the display profile. I know this is confused (either FF is confused or the OS is confused, not sure which) in multiple display situations. But at least for single display it should get the correct profile so long as it's been set as the current display profile (and on Windows set as the default as well).
All of Adobe's products inquire with ICM/WCS/ColorSync as to the current display profile so there is no UI for selecting a display profile in those apps. And in my view that's the way all applications should work.
Not setting display_profile didn't change things.
Alright, I'm kinda dry now, as far as experimenting is concerned :)
I tried setting my monitor to its sRGB emulation preset, but it looks really craptastic, even re-calibrated from there...
You guys are positive this has been tested on a real, wide gamut monitor?
I still have problems with my dell monitor and firefox :(
This bug in particular I think is fixed, I don't get over-saturated images anymore, but maybe something is not working as expected
Look here and see if applies to your troubles: https://bugzilla.mozilla.org/show_bug.cgi?id=509273
Re: using a wide gamut display. I have an NEC LCD3090WQXi which is a wide gamut display and except for some troubles with 3.5.x and sometimes also on OS X 10.6 it has been working. I think there were some hiccups with the transition to qcms.
Currently on Mac OS X 10.5.8 and 10.6.1 I am getting expected results, which are within 1 value (8bpc, 0-255) of what I get from Photoshop CS4 using the following build:
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.3a1pre) Gecko/20091103 Minefield/3.7a1pre
On 10.6.1, the following build appears to not do any display compensation at all which makes colors on the web appear very saturated. By no display compensation I mean color management of any kind is not occurring, the Raw values in the file are going to the display, even when the test image is tagged with an embedded profile:
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:22.214.171.124) Gecko/20091016 Firefox/3.5.4
@Michele: yes, I definitely see the same problem, that's problematic.
@Chris: thanks, that's good news, I was actually going to pull the trigger on a NEC LCD2690WQXi2, and I'm glad you are reporting it could work with FF. However, could you please do me a favor and perform the simple test described in bug 509273? I definitely see a big difference between this test pic when I open it in PS and LR, compared to FF 3.5, 3.7 and to some extent 3.0.