509273 - qcms renders wrong colors in tagged image

Status: RESOLVED DUPLICATE of bug 488800

(Core :: Graphics: Color Management, defect)

Description

[Michele]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.2) Gecko/20090731 Shiretoko/3.5.2 (tete009 SSE2 PGO)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.2) 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?

Comment 1

[Michele]

Attachment: Firefox 3.5.2

Comment 2

[Michele]

Attachment: Safari 4

Comment 3

[Michele]

Attachment: Photoshop

Comment 4

[Michele]

Attachment: Open this in photoshop, nice overview

Comment 5

[Michele]

Attachment: Dell 2007wfp profile

Comment 6

[Michele]

Attachment: Dell 2408WFP profile

Comment 7

[Danir Ivanovich]

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.

Comment 8

[purple2k]

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.

Comment 9

[Jeff Muizelaar [:jrmuizel]]

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.

Comment 10

[Jeff Muizelaar [:jrmuizel]]

Fixing bug 509710 should help here.

Comment 11

[Michele]

ah :D

thanx for your explanation, I will keep an eye on that bug too...

Comment 12

[pierre]

Same problem here on my DELL 2709 wfp.
Using gentoo linux and Firefox 3.5.4

Comment 13

[sebastien.barre]

Michele, can you attach the image you want us to open in Photoshop? The overview one is confusing.

Comment 14

[Michele]

it's the jpeg in the URL
this one: http://img12.imageshack.us/img12/6392/thewatchdog.jpg

Comment 15

[Michele]

Save http://img12.imageshack.us/img12/6392/thewatchdog.jpg on your disk, open the same image in photoshop and firefox, compare.
I see significant differences

Comment 16

[sebastien.barre]

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.

Comment 17

[Chris Murphy]

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

Comment 18

[Chris Murphy]

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.

Comment 19

[Michele]

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

Comment 20

[Chris Murphy]

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?

Comment 21

[sebastien.barre]

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

Comment 22

[sebastien.barre]

Attachment: The Dell C22W generic profile, available at Dell support

Comment 23

[sebastien.barre]

Attachment: My Dell C22W profile, created using Huey Pro (most likely ICCv4)

Comment 24

[Michele]

my attached 2007wfp profile is provided by Dell (automatically downloaded and
installed via windows update)

Comment 25

[Chris Murphy]

OK please confirm:

Problem is reproducible for these profiles:
393405
393406

Problem is not reproducible with these profiles:
410494
410496

The two profiles just posted don't have the negative characteristics of the first two.

Comment 26

[sebastien.barre]

I can confirm my part, I used 410494 and 410496 on my C22W, and I see the problem.

Comment 27

[purple2k]

Don't forget about my dell 2408wfp profile, also exhibits the same problem.

(looks much darker in dark areas than it should)

Comment 28

[Michele]

I can confirm profiles 393405/6 are affected too

Then all the profiles attached suffer the same problem

Comment 29

[Chris Murphy]

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.

Comment 30

[sebastien.barre]

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

Comment 31

[sebastien.barre]

Attachment: PS CS4 vs. Minefield (trunk build 11/05/09) on Vista 64 bits, Dell C22W monitor and "Dell C22W at Home C22W KM352815169S.icc"

Comment 32

[Chris Murphy]

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.

Comment 33

[sebastien.barre]

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

Comment 34

[Chris Murphy]

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.

Comment 35

[Chris Murphy]

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.

Comment 36

[Chris Murphy]

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.

Comment 37

[Garret Wilson]

Attachment: Dell 2407WFP-HC color profile

Comment 38

[Garret Wilson]

Attachment: Spyder 2407WFP-HC color profile

Comment 39

[Garret Wilson]

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 http://www.color.org/icc_specs2.xalter 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.

Comment 40

[Benoit Girard (:BenWa)]

The solution is to enable icc v4 support by default to use the color lookup tables instead of the TRCs