548.11 KB, image/jpeg
768.04 KB, image/png
822.44 KB, image/png
927.59 KB, image/png
100.46 KB, application/octet-stream
4.10 KB, patch
|Details | Diff | Splinter Review|
100.41 KB, application/octet-stream
100.41 KB, application/octet-stream
288.21 KB, image/jpeg
290.43 KB, image/jpeg
102.92 KB, application/zip
3.88 KB, application/octet-stream
12.21 KB, application/zip
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 Reproducible: Always Steps to Reproduce: 1.get a good monitor: dell, nec, wide gamut in general 2.open http://img241.imageshack.us/img241/8656/cv07wbra105003.jpg 3.see differences with the same image rendered with photoshop or other browsers Actual Results: Images look darker, oversaturated, way too much different from the correct ones. Expected Results: 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)
Attachment #382510 - Attachment description: the image as showed in firefox 3.0.10 (color profile support ENABLED) → 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.
Attachment #382508 - Attachment description: the image as showed in firefox 3.0.10 (color profile support DISABLED) → the image as showed in firefox 3.0.10 (color management DISABLED)
can be useful to understand what's going on.
Attachment #382511 - Attachment description: how 3.5/3.6 render the same image → the same image in firefox 3.5/3.6
Component: General → GFX: Color Management
Product: Firefox → Core
Version: 3.5 Branch → 1.9.1 Branch
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.
Assignee: nobody → jmuizelaar
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
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 ;) thx
This patch should make things better, though perhaps not perfect.
A build with the patch should eventually show up here: https://build.mozilla.org/tryserver-builds/?C=M;O=D It should have a name something like: firstname.lastname@example.org/
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?
Use at least 256 entries, add a bunch of comments, and update to upstream qcms.
Attachment #382771 - Flags: review?(joe) → review+
Jeff, I tried your test build and it works perfectly on my Dell S2409W! Seems you got the bug nailed.
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
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.
Flags: blocking1.9.1? → blocking1.9.1-
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. Oh well.
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: http://www.garretwilson.com/blog/2009/06/03/colorprofiles.xhtml http://www.garretwilson.com/blog/2009/06/30/firefox35colormanagement.xhtml
(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?
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.
http://img31.yfrog.com/img31/3988/firefox35colorbug.png 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?
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] Updated patch Approved for 220.127.116.11. a=ss
Attachment #382771 - Flags: approval18.104.22.168? → approval22.214.171.124+
Probably related to this bug: FF 3.5.1 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).
Verified fixed on the 1.9.1 branch using Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:126.96.36.199) 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) > http://img31.yfrog.com/img31/3988/firefox35colorbug.png > > 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: http://www.getcolormanaged.com/images/090721_LaCie_LUT.icc http://www.getcolormanaged.com/images/090721_LaCie.icc 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.
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).
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: > http://www.getcolormanaged.com/images/090721_LaCie_LUT.icc > http://www.getcolormanaged.com/images/090721_LaCie.icc > > 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.
(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.
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: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/ Let me know if it doesn't.
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? Thank you
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?
Chris, Jeff, 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? In 3.0.x: 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. Thanks
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? Thanks
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:188.8.131.52) 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. https://bugzilla.mozilla.org/show_bug.cgi?id=509273 Thanks
You need to log in before you can comment on or make changes to this bug.