Closed Bug 509273 Opened 15 years ago Closed 13 years ago

qcms renders wrong colors in tagged image


(Core :: Graphics: Color Management, defect)

1.9.1 Branch
Windows 7
Not set





(Reporter: skryabin, Assigned: BenWa)





(11 files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv: Gecko/20090731 Shiretoko/3.5.2 (tete009 SSE2 PGO)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20090729 Firefox/3.5.2

I can reproduce this in two different monitors: a dell 2007wfp (s-ips panel) and a dell 2408WFP (wide gamut s-pva)
I attach the color profiles.

The image in firefox 3.5.2 is too black in dark areas (too much contrast?) and in the left wall shows a bit of posterization too.

Reproducible: Always

Steps to Reproduce:
1.Open the image in the link preferably on a good monitor (a Dell?)
2.Open the same image in Photoshop or Safari
3.See the differences in the dark areas and notice posterization in left wall.
Actual Results:  
Dark areas tend to black, posterization in the left wall

Expected Results:  
Open the same image in Photoshop or safari: you will see much more detail in the dark areas (the windows on the center building) and no posterization on left wall.
This is how image should render, or not?
Attached image Firefox 3.5.2
Attached image Safari 4
Attached image Photoshop
Version: unspecified → 1.9.1 Branch
Attached file Dell 2007wfp profile
Attached file Dell 2408WFP profile
Assignee: nobody → jmuizelaar
Same issue on my Dell2408WFP. It seems that new engine works fine with the saturation of the colors but not correct on the contrast. The lower area of the picture looks dark, i can't see well the windows. And the wall on the left looks a little posterized. There is also some color cut issues, noticed on the dog area.
I think that the problem looks pronounced on wide gamut devices and a little bit less evident on regular gamut screens.

Jeff, I'm totally available if you need more images comparison or other kind of testing.
I can confirm that on a DELL 2408wfp wide-gamut monitor the colors are off.

I find firefox 3.5.x unusable in its current state with this monitor. With color management off, everything is over-saturated (due to wide gamut). With color management on (using dell's profile) - colors are no longer saturated, but the contrast is bad and things are darker than they should be.

Works perfectly on firefox 3.0.x tho, so I'm using that version now.
The reason for the difference here is likely because we don't use A2B0 mft2 lookup tables and instead use the tone reproduction curves. However, the tone reproduction curves in those profiles only have 5 points so they are probably not as accurate as they should be.
Fixing bug 509710 should help here.
ah :D

thanx for your explanation, I will keep an eye on that bug too...
Same problem here on my DELL 2709 wfp.
Using gentoo linux and Firefox 3.5.4
Michele, can you attach the image you want us to open in Photoshop? The overview one is confusing.
it's the jpeg in the URL
this one:
Save on your disk, open the same image in photoshop and firefox, compare.
I see significant differences
Thanks Michele.

I definitely confirm the same problem on my Dell C22w (Crystal) Wide Gamut monitor. It looks much darker in dark areas in both Firefox 3.5.4 and 3.7a1, where you pointed (the building in the lower right). It not as bad in Firefox 3.0.15, but still different from what I see in both Photoshop CS4, and FastPictureViewer.
Unable to reproduce with:

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.3a1pre) Gecko/20091104 Minefield/3.7a1pre

Hardware: Macbook Pro 4,1 / NEC LCD3090WQXi, Spectraview 2 1.1.03 / connected via D-DVI with the "menu bar" set to the NEC external display so it's considered the primary display

OS version: 10.6.1
Bit more detail. Between Photoshop CS4 11.01 and the aforementioned version of FF, there is usually 0 level difference in all channels for most pixels, with a maximum single channel differential of 3 levels (0-255), maximum total for all three channels combined of 4 levels.
(In reply to comment #16)
> Thanks Michele.
> It looks much darker in dark areas in both Firefox 3.5.4 and 3.7a1,
> where you pointed (the building in the lower right). It not as bad in Firefox

yep, the dark details are totally lost (the windows)
can you see also that bit of posterization effect on the left wall?
I can reproduce this problem if I set my display with either of the attached display profiles. So there is something about these profiles that qcms handles differently than ACE. If I had to guess, it's qcms is using the really crappy TRC tags in these profiles (as in stunningly bad), and Photoshop is using the mft2 tags. But I'll see if I can find out what they are doing and if this profile is malformed or what.

What is the provenance of these two Dell profiles? Are they from the Dell website? Or what?
@Chris: thanks for testing. Now I might be off base here, but is the NEC3090 a good example? From what I recall, it's one of the few monitors that is hardware calibrated; by that I mean that once you calibrate it with SpectraView, it stores the LUT and calibration parameters back *in* the monitor. It still generates an ICC profile, but most (if not all) the calibration/color correction is done in hardware by the monitor. For all intent and purposes, you can reinstall a fresh OS, turn the monitor on, and it will look calibrated without much help from an ICC profile. So I'm wondering if the test in FF, in this situation, is looking OK because there isn't actually much to do in terms of software color correction. In our case though, the correction/management is entirely driven by the ICC profile in software, and maybe that's where FF hit a bug, because there is much more to do (in the math)?

UPDATE: didn't see your new finding in #20. Great, glad you can reproduce it. I'll attach my profiles as well.
my attached 2007wfp profile is provided by Dell (automatically downloaded and
installed via windows update)
OK please confirm:

Problem is reproducible for these profiles:

Problem is not reproducible with these profiles:

The two profiles just posted don't have the negative characteristics of the first two.
I can confirm my part, I used 410494 and 410496 on my C22W, and I see the problem.
Don't forget about my dell 2408wfp profile, also exhibits the same problem.

(looks much darker in dark areas than it should)
I can confirm profiles 393405/6 are affected too

Then all the profiles attached suffer the same problem
Are you quitting Firefox or Minefield after changing the profiles, and then relaunching?

The two new profiles don't have the structural defect I'm seeing in the first two profiles, and I'm also not able to reproduce the Firefox-Photoshop discrepancy with these new profiles.
@Chris: yes Chris, I am quitting FF and/or Minefield each time. I'll try to create a composite screenshot of Photoshop vs. Minefield tonight.
OK so just to re-iterate my findings on OS X 10.6.1 the profiles in attachments 393405 and 393406 contain structurally valid TRC information that is likely false. That is, I consider this a problem with the profiles themselves.

The reason why Photoshop and Lightroom don't have issues with them is because they are using the mft2 tags in those profiles, which do not have the problem. Whereas qcms is deferring to the problematic data in the rgbTRC tags.

Profiles in attachments 410494 and 410496 appear to be fine to me, and I get the same results between Photoshop and FF 3.7pre1 when either profile is set as my current display profile.

BTW, it would be useful if there were a way to find what display profile Firefox is currently compensating for, even if this were only available in the nightlies.
@Chris: thanks. So we are using the same Photoshop and Firefox, but you can't reproduce the problem, so it's either at the OS level (you are on MacOSX, I'm on Vista), or at the monitor level (you have a high-end NEC, I have a Dell)...

Let me know how I can help. I don't know how to output which display profile Firefox is currently compensating for.

Is qcms a third party library? Do you know which developers are involved in color management in FF 3.7? You? Can we contact them somehow? It seems to me that at least your findings about 393405 and 3943406 exhibit a bug. Maybe fixing it might help my own issue...
This bug has two different problems going on in it, and those two problems likely need to be separated by the powers that be into separate bugs for tracking and identification.

Problem A has to do with the original profiles. Those profiles simply have crummy data in the rgbTRC tags. It's not a flaw per se in qcms, but is is unfortunate that qcms as yet isn't deferring to mft2 tags instead. So this isn't a bug, but rather a feature request.

Problem B has to do with the second two profiles but I'm not seeing any problems with their structure, or contents that could explain the description given. We need this reproduced on more machines to hopefully figure out what's going on. Since I can't reproduce, I'm not sure what might be up.

And the engineers are all lurking. I'm not one of them. So consider them contacted already. What they need is something consistently reproducible.
Jeff, my suggestion is that this bug be turned into a feature request for qcms to support mft2 tags and defer to them if present in the profile. And then need a new bug written up clearly describing the issue with the 2nd set of profiles posted, new screen shots, and steps for reproducing. Maybe someone with Vista can give this a shot.
Oh and with respect to displays being a factor, I'd say sorta. Since the NEC I'm using is extremely well behaved due to hardware level calibration, when I set a different display's profile as my display profile, problems in the newly set profile tend to be much more obvious on this NEC rather than an ordinary display. Not only am I not seeing a difference, when I take a screen capture of the test image supplied (as well as my own) into Photoshop CS4 as well as FF 3.7 pre1, and then take both into Photoshop, copy one as a layer into the other and do a difference blending mode on them, I'm getting almost identical pixel for pixel values between the two applications (~3 level max in single channel and ~5 level max combined among all three channels). Those differences aren't enough for most people to see and I'm relatively unconcerned with such differences.
I just uploaded two color profiles for the Dell 2407WFP-HC. The stock Dell version exhibits the same posterization mentioned here. I believe that the root cause is the same: the TRCs are only providing five points, and Firefox is using the TRCs rather than the A2B0 section.

The Spyder profile for the 2407WFP-HC has no A2B0 section, but apparently its TRCs are more fine-grained and therefore do not result in the huge color jumps and posterization. If you read the ICC specification at section 8.10, it appears that the A2B0 tag takes priority over the TRCs.

Note that I'm making many assumptions here---I'm not an expert, and much of this is new to me, so I apologize if my assessment isn't correct.

Comparisons of the two profiles was done using a private, unreleased build of FastPictureViewer that apparently uses WCS for color management. This build of FPV exhibits the same posterization as does Firefox 3.5.x when used with the stock Dell color profile.
Assignee: jmuizelaar → bgirard
The solution is to enable icc v4 support by default to use the color lookup tables instead of the TRCs
Closed: 13 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.