498245 - some images displays with wrong colours (green becomes purples, etc)

Status: RESOLVED FIXED

(Core :: Graphics: Color Management, defect)

Description

[baldurien]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b99) Gecko/20090605 Firefox/3.5b99 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b99) Gecko/20090605 Firefox/3.5b99 (.NET CLR 3.5.30729)

On some website (like mine as given in URL field) or http://www.hayaku-trad.com/ displays with wrong colors. For instance, the https://bugzilla.mozilla.org/skins/custom/images/bugzilla.png icon is normally displayed with a green bug.

On fx3.5b99, it is displayed with a blue bug - with or without extension (also tried a new profile).

While the image works totally fine in Firefox 3.0.11 and other browser such as Opera.


 

Reproducible: Sometimes

Steps to Reproduce:
1. Browse site with Firefox 3.5b99 (or anything that would be newer, I tested with last Shiretoko for instance)
2. Browse site with Opera, Internet Explorer 8, or even Firefox 3.0.11
3. See that some image does not display correctly at all.
Actual Results:  
See http://www.bbnwn.eu/nwn/images/interface/defaut/menu/undrentide.jpg

The image is not well displayed.



Expected Results:  
The result should be the same - except from the text - than http://www.bbnwn.eu/nwn/images/interface/defaut/menu/lejeu.jpg

Also fails on http://www.hayaku-trad.com/ (you see a purple webpage)

I would also say that it works fine on my brother's PC.

Here is my config:

===================================================
GPU Caps Viewer v1.7.0
http://www.ozone3d.net/gpu_caps_viewer/
===================================================


===================================[ System / CPU ]
- CPU Name: Intel(R) Core(TM)2 CPU          6400  @ 2.13GHz
- CPU Core Speed: 2134 MHz
- CPU Num Cores: 2
- Family: 6 - Model: 15 - Stepping: 6
- Physical Memory Size: 2046 Mb
- Operating System: Windows XP build 2600 [Service Pack 3]
- DirectX Version: 9.0c
- PhysX Version: 71113


===================================[ Graphics Adapter / GPU ]
- OpenGL Renderer: GeForce 7900 GTO/PCI/SSE2
- Drivers Renderer: NVIDIA GeForce 7900 GT/GTO
- DB Renderer: NVIDIA GeForce 7900 GTO
- Device Description: NVIDIA GeForce 7900 GT/GTO
- Adapter String: GeForce 7900 GTO
- Vendor: NVIDIA Corporation
- Vendor ID: 0x10DE
- Device ID: 0x0291
- Drivers Version: Forceware 6.14.11.8250 (3-27-2009)
- GPU Codename: G71
- GPU Unified Shader Processors: 0
- GPU Vertex Shader Processors: 8
- GPU Pixel Shader Processors: 24
- Video Memory Size: 512 Mb
- BIOS String:  5.71.22.39.09
- Current Display Mode: 1280x1024 @ 75 Hz - 32 bpp

Comment 1

[baldurien]

Attachment: How the bugzilla icon displays in Fx3.5b99

This image was taken while using Fx3.5b99

Comment 2

[baldurien]

Attachment: How the bugzilla icon displays in Fx3.0.11

This is how it looks fine in Fx3.0.11.

Comment 3

[Ria Klaassen (not reading all bugmail)]

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1pre) Gecko/20090609 Shiretoko/3.5pre

http://www.hayaku-trad.com/ has a kind of salmon color here. And bugzilla bugs are always green. Maybe updating your video driver will help?

Comment 4

[baldurien]

I will try tonight, but I thought having problem with graphic driver would do the same problem in any application, not just 3.5b99? Or Fx 3.5b99 (I should check 3.5b4 to see if it bug too) use Video Card to render display? 


1. On www.bbnwn.eu, this should bug on all the images, but only a few are impacted, and they use the same template - I know, 'cause it's my site.
2. As I said, on my brother's PC, this works fine. Check the two images I sent, you will see what I mean.

Comment 5

[baldurien]

Attachment: Second screenshot on fx3.5b99

This is another screenshot, took when I removed my display driver: as you can see, the bugzilla icon display well in the Adress bar. So, I don't think that is due to my video driver.

Comment 6

[Jeff Muizelaar [:jrmuizel]]

(In reply to comment #4)
> I will try tonight, but I thought having problem with graphic driver would do
> the same problem in any application, not just 3.5b99? Or Fx 3.5b99 (I should
> check 3.5b4 to see if it bug too) use Video Card to render display? 

The color problems will only show up if the applications are using your display's color profile. Firefox 3.0.11 and Opera do not use the display's color profile.

> 
> 1. On www.bbnwn.eu, this should bug on all the images, but only a few are
> impacted, and they use the same template - I know, 'cause it's my site.

Only tagged images are color corrected. So the images that are tagged with a color profile are probably the ones that show up wrong.

If you could attach the color profile used by your display, that could be helpful.

Comment 7

[baldurien]

I do not have any ICC Profile (if you speak about the Color managment tab under Parameters in the Screen display).

However, one of the wrong image (http://www.bbnwn.eu/nwn/images/dlgamer/dlgamer_neverwinter2_dispo_FR.jpg) does have such profile :

sRGB IEC61966-2.1
sRGB IEC61966-2.1

Copyright (c) 1998 Hewlett-Packard Company

WhitePoint : D65 (daylight)

But I don't know how to export it (using The Gimp).

Comment 8

[baldurien]

Attachment: My Color Profile

Without this color profile (for my BenQ FP93V 19" LCD Screen), all is just fine. 

But when installed, it isn't. I attached the color profile - and I am still wondering why it affect some images and not others while they use the same template.

Comment 9

[Jeff Muizelaar [:jrmuizel]]

The profile for your monitor is bogus, however our current code for catching that doesn't catch yours. Chris what would you suggest we do?

Comment 10

[Chris Murphy]

In order:

a.) Advocate public pantsing of the person responsible for the creation of this profile. This is high-order sabotage.

b.) Have FF ignore display profiles, in favor of sRGB, when any of the primaries use negative XYZ values. (Partial fix because that's just the most obvious thing that's wrong with this particular profile.)

c.) We need to look at the existing code that deals with adding up the XYZ's and comparing it to white. R + G + B must equal one of two white points: either D50 XYZ, or what's in the wtpt tag. We do have a tolerance for this but I forget what we did. At first glance, it seems to me this existing code should have caught this because these XYZ's I don't think add up to white. (FWIW, this profile's wtpt tag is the same as D50 white.)

Comment 11

[Chris Murphy]

OK I just added up the XYZs and sure enough it adds up to D50 white. Amazing, and only possible because the blue primary is imaginary. (The red primary, btw, is a laser beam.)

So the original advice b.) above stands. Ignore display profiles containing negative XYZ values.

As for comment c.) above, please disregard. I think we are fine.

Comment 12

[Jeff Muizelaar [:jrmuizel]]

Attachment: Profiles with negative colorant tristiumlus values are bogus

Comment 13

[Jeff Muizelaar [:jrmuizel]]

Attachment: Check that the profile is an RGB profile before checking if it's bogus

Comment 14

[Chris Murphy]

For what it's worth, the ICC specification of all versions states that CIEXYZ tristimulus values cannot be negative.

Comment 15

[Bobby Holley (:bholley)]

Comment on attachment 385105 [details] [diff] [review]
Profiles with negative colorant tristiumlus values are bogus

looks good. r=bholley

Comment 16

[Bobby Holley (:bholley)]

Comment on attachment 385106 [details] [diff] [review]
Check that the profile is an RGB profile before checking if it's bogus

r=bholley here too

Comment 17

[Jeff Muizelaar [:jrmuizel]]

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

Comment 18

[Marti]

Just a small comment: it is certainly possible for an ICC profile to have negative numbers in the colorant tags, as this matrix does incorporate chromatic adaptation as well. See CIERGB.icc from Adobe for an example of a perfectly legal profile that has negative numbers.

Comment 19

[Chris Murphy]

The present ICC spec explicitly disallows negative XYZ values. CIERGB is a unique case, and there are others due to limitations in the colorspace class. Going forward, unique color spaces like this should use the colorspace class, not the display device class. No conventional display device has primaries described with negative tristimulus values. 

In the case of CIERGB, its primaries are monochromatic, so you'd need a display device made up of laser beams to produce those primaries. If we end up with monochromatic imaging devices drawing directly onto the retina, the ICC will likely need to manage this with a spec change not just to allow negative numbers (if needed) in the profile format, but also so CMMs can consistently handle them properly.

Comment 20

[Marti]

Chris,

 Table G.2 — Three-component matrix-based input profile required tags

As you see, the ICC spec does not claim at all, that the tag would contain any primary, or an adapted primary, but just a matrix column. 

F.2 Three-component matrix-based profiles

"The 3x3 matrix converts these linearized values into XYZ values which can then be encoded into CIEXYZ PCS values as specified in 6.3.4."

Which does not disallow negative matrix values. Please note this tag does contain the chromatic adaptation as well. Is the chromatic adaptation what makes numbers to reach negative.

See here the creation of sRGB:
http://www.mendeley.com/download/public/854/136138/6c6f3bcc4cacc1c8d9dc2358a3e7e57c10e8cba4

The names of those tags were renamed from cmsSigBlueColorantTag (etc.) to cmsSigBlueMatrixColumnTag (etc.) in v4.1 to enforce this idea.

Regards
Marti

Comment 21

[Chris Murphy]

From the v4.2 spec:

8.4.3 Applies because we are talking about 3-component matrix-based display profiles. This section requires the use of redMatrixColumnTag (and others).

9.2.33 redMatrixColumnTag uses only XYZType numbers.

10.27 XYZType explicitly says tristimulus values shall be non-negative.


From the v3.0 spec (format 2.0):

3.2.2 requires redColorantTag

5.34 redColorantTag requires use of XYZType

6.21 XYZType requires non-negative tristimulus values

Comment 22

[Marti]

:-)

Ok, for me is fine if you want to keep the bug closed. I just pointed out the issue because it was discussed in a recent ICC meeting. You can check the ICC reference implementation and Argyll if you wish. I think we should publish a technical note on that... 

http://www.color.org/sampleicc.xalter

Regards
Marti

Comment 23

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

Jeff: Which patch(es) is/are needed for 1.9.1? Is there testing for this? I didn't see a test in the patch.

Comment 24

[Jeff Muizelaar [:jrmuizel]]

(In reply to comment #23)
> Jeff: Which patch(es) is/are needed for 1.9.1? Is there testing for this? I
> didn't see a test in the patch.

The more important patch is:
Profiles with negative colorant tristiumlus values are bogus
https://bugzilla.mozilla.org/attachment.cgi?id=385105

The second patch,
Check that the profile is an RGB profile before checking if it's bogus 
https://bugzilla.mozilla.org/attachment.cgi?id=385106
avoids a unlikely crash.

There is no testing for this as it's not very easy to test because it depends on the user's display profile.

There is work in bug 466875 about updating the cms testing framework.

Comment 25

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

Comment on attachment 385106 [details] [diff] [review]
Check that the profile is an RGB profile before checking if it's bogus

Thanks for the details Jeff. I'm going to push this to 1.9.1.3 since we're getting pretty filled up for 1.9.1.2.

Comment 26

[Daniel Veditz [:dveditz]]

Comment on attachment 385105 [details] [diff] [review]
Profiles with negative colorant tristiumlus values are bogus

Approved for 1.9.1.4, a=dveditz for release-drivers

Comment 27

[Daniel Veditz [:dveditz]]

Comment on attachment 385106 [details] [diff] [review]
Check that the profile is an RGB profile before checking if it's bogus

Approved for 1.9.1.4, a=dveditz for release-drivers

Comment 28

[Daniel Veditz [:dveditz]]

Comment on attachment 385105 [details] [diff] [review]
Profiles with negative colorant tristiumlus values are bogus

past code-freeze for 1.9.1.4, removing non-blocker approval.

Comment 29

[philipn]

This patch introduced bug 1250461 (https://bugzilla.mozilla.org/show_bug.cgi?id=1250461), as now there are millions of users on P3 display Macs with negative colorant tristiumlus values.