497363 - qcms renders wrong colors on some "good" monitors

Status: RESOLVED FIXED

(Core :: Graphics: Color Management, defect)

Description

[Michele]

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)

Comment 1

[Michele]

Attachment: the original image

Comment 2

[Michele]

Attachment: the image as showed in firefox 3.0.10 (color management DISABLED)

Comment 3

[Michele]

Attachment: the image as showed in firefox 3.0.10 (color management ENABLED)

Comment 4

[Michele]

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.

Comment 5

[Michele]

Attachment: the same image in firefox 3.5/3.6

TOO DARK!

Comment 6

[Michele]

Attachment: the icm color profile of my monitor.

can be useful to understand what's going on.

Comment 8

[Michele]

ok, I was creating a new bug because of the wrong QA Contact, feel free to keep one of the two bugs active ;)

Comment 9

[Jeff Muizelaar [:jrmuizel]]

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.

Comment 10

[Michele]

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.

Comment 11

[Jeff Muizelaar [:jrmuizel]]

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.

Comment 12

[Michele]

nice to hear that ;)

thx

Comment 13

[Jeff Muizelaar [:jrmuizel]]

Attachment: Always use 256 entries in the inverted lut

This patch should make things better, though perhaps not perfect.

Comment 14

[Jeff Muizelaar [:jrmuizel]]

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:
[e-mail]-qcms-invert/

Comment 15

[Michele]

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.

Comment 16

[Michele]

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?

Comment 17

[Jeff Muizelaar [:jrmuizel]]

Attachment: Updated patch

Use at least 256 entries, add a bunch of comments, and update to upstream qcms.

Comment 18

[Recall]

Jeff, I tried your test build and it works perfectly on my Dell S2409W! Seems you got the bug nailed.

Comment 19

[Jeff Muizelaar [:jrmuizel]]

http://hg.mozilla.org/mozilla-central/rev/f6609f07b14f

Comment 20

[Mike Beltzner [:beltzner, not reading bugmail]]

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.

Comment 21

[Mike Shaver (:shaver emeritus)]

Agree: ridealong but not reason enough to force another rev.

Comment 24

[Bobby Holley (:bholley)]

did this make it into rc2?

Comment 25

[Cpuroast]

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.

Comment 26

[Bobby Holley (:bholley)]

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...

Comment 27

[Cpuroast]

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.

Comment 33

[Garret Wilson]

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

Comment 34

[Jeff Muizelaar [:jrmuizel]]

(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?

Comment 35

[Garret Wilson]

Attachment: 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.

Comment 36

[Jeff Muizelaar [:jrmuizel]]

(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

Comment 37

[Garret Wilson]

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 )

Comment 38

[Jeff Muizelaar [:jrmuizel]]

(In reply to comment #37)
> The question is, when will I see 3.5.1?

mid-to-late July perhaps.

Comment 39

[Gerben]

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?

Comment 43

[Sebastian Bergmann]

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?

Comment 44

[Samuel Sidler (old account; do not CC)]

Won't block on this, but I'll approve the patch.

Comment 45

[Samuel Sidler (old account; do not CC)]

Comment on attachment 382771 [details] [diff] [review]
Updated patch

Approved for 1.9.1.1. a=ss

Comment 47

[René Damkot]

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.

Comment 48

[Cedric]

Bug still present with 3.5.1 :-(, i don't understand why the bug status is "fixed" ?

Comment 49

[Steve England [:stevee]]

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).

Comment 52

[Jeff Muizelaar [:jrmuizel]]

http://hg.mozilla.org/releases/mozilla-1.9.1/rev/cb58df6e256c

Comment 55

[Marcia Knous [:marcia]]

Verified fixed on the 1.9.1 branch using Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.2) Gecko/20090729 Firefox/3.5.2. I verified using the image in the URL field with a pretty good Dell monitor.

Comment 56

[Chris Murphy]

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.

Comment 57

[Sebastian Bergmann]

Firefox 3.5.2 solved the issue for me. Thanks!

Comment 58

[Chris Murphy]

(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.

Comment 59

[René Damkot]

3,5,2 still won't play nice with my table based monitor profile.
Guess I'll keep using flock then...

Comment 60

[Chris Murphy]

(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.

Comment 61

[René Damkot]

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.

Comment 62

[purple2k]

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.

Comment 63

[purple2k]

Attachment: Color profile for Dell 2408WFP

Color profile for Dell 2408WFP

Comment 64

[rhgg2]

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).

Comment 65

[rhgg2]

Attachment: Image displayed in Firefox 3.5.2, color management OFF

Comment 66

[rhgg2]

Attachment: Image displayed in Firefox 3.5.2, color management ON

Comment 67

[purple2k]

Is anyone actually monitoring this bug page?

I ask because I see that it's marked as FIXED and RESOLVED (which it's not).

Comment 68

[Jeff Muizelaar [:jrmuizel]]

(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.

Comment 69

[Danial Horton]

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?

Comment 70

[Danial Horton]

Btw, when saved and opened in a program that honours the tagged profile, it appears correctly.

Comment 71

[Danial Horton]

Attachment: DSUB and DVI profiles for my BenQ G2400WD

Comment 72

[Jeff Muizelaar [:jrmuizel]]

(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.

Comment 73

[pierre]

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 ?

Comment 74

[sebastien.barre]

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...

Comment 75

[Jeff Muizelaar [:jrmuizel]]

(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.

Comment 76

[sebastien.barre]

Attachment: Color Profile for a Dell C22W Wide Gamut monitor.

Here is the profile. Thank you very much.

Comment 77

[Chris Murphy]

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.

Comment 78

[Jeff Muizelaar [:jrmuizel]]

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.

Comment 79

[sebastien.barre]

Attachment: 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.

Comment 80

[sebastien.barre]

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

Comment 81

[Chris Murphy]

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?

Comment 82

[sebastien.barre]

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

Comment 83

[Chris Murphy]

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.

Comment 84

[sebastien.barre]

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

Comment 85

[Michele]

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

Comment 86

[Chris Murphy]

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:1.9.1.4) Gecko/20091016 Firefox/3.5.4

Comment 87

[sebastien.barre]

@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