Closed Bug 498245 Opened 12 years ago Closed 12 years ago
some images displays with wrong colours (green becomes purples, etc)
24.69 KB, image/png
25.48 KB, image/png
29.78 KB, image/jpeg
100.29 KB, application/octet-stream
2.28 KB, patch
|Details | Diff | Splinter Review|
822 bytes, patch
|Details | Diff | Splinter Review|
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 188.8.131.5250 (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: 184.108.40.206.09 - Current Display Mode: 1280x1024 @ 75 Hz - 32 bpp
This image was taken while using Fx3.5b99
This is how it looks fine in Fx3.0.11.
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?
Component: General → GFX: Thebes
Product: Firefox → Core
QA Contact: general → thebes
Version: unspecified → 1.9.1 Branch
Component: GFX: Thebes → GFX: Color Management
QA Contact: thebes → color-management
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.
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.
(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.
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).
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.
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?
Assignee: nobody → jmuizelaar
Status: UNCONFIRMED → NEW
Ever confirmed: true
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.)
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.
For what it's worth, the ICC specification of all versions states that CIEXYZ tristimulus values cannot be negative.
Attachment #385105 - Flags: review?(bobbyholley) → review+
Comment on attachment 385105 [details] [diff] [review] Profiles with negative colorant tristiumlus values are bogus looks good. r=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
Attachment #385106 - Flags: review?(bobbyholley) → review+
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
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.
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.
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
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
:-) 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
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.
Attachment #385105 - Flags: approval220.127.116.11?
Attachment #385106 - Flags: approval18.104.22.168?
(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.
Attachment #385105 - Flags: approval22.214.171.124? → approval126.96.36.199?
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 188.8.131.52 since we're getting pretty filled up for 184.108.40.206.
Attachment #385106 - Flags: approval220.127.116.11? → approval18.104.22.168?
Comment on attachment 385105 [details] [diff] [review] Profiles with negative colorant tristiumlus values are bogus Approved for 22.214.171.124, a=dveditz for release-drivers
Attachment #385105 - Flags: approval126.96.36.199? → approval188.8.131.52+
Comment on attachment 385106 [details] [diff] [review] Check that the profile is an RGB profile before checking if it's bogus Approved for 184.108.40.206, a=dveditz for release-drivers
Attachment #385106 - Flags: approval220.127.116.11? → approval18.104.22.168+
Comment on attachment 385105 [details] [diff] [review] Profiles with negative colorant tristiumlus values are bogus past code-freeze for 22.214.171.124, removing non-blocker approval.
Attachment #385105 - Flags: approval126.96.36.199+ → approval188.8.131.52-
Attachment #385106 - Flags: approval184.108.40.206+ → approval220.127.116.11-
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.
You need to log in before you can comment on or make changes to this bug.