Firefox 3.5 and up renders certain graphics with wrong colors (for gfx.color_management.mode = 2) (8.632)

Created an attachment (id=374939)
Screenshot #1 (jpg) showing bug

Created an attachment (id=374941)
Screenshot #2 (jpg) showing bug

The image shown in this screenshot is attachment #3.

Created an attachment (id=374942)
Example image (shown in screenshot #2)

This doesn't occur when, running the same build of firefox on the same machine, I forward X to another display.

It smells then like an X server or video driver bug (Xorg 1.4.0.90, fglrx 8.58.2). However, since the problem doesn't occur with Firefox 3.0, so it's still possible this is a 3.5 bug.

If you decide to resolve this as INVALID, I'll report it on Ubuntu's bug tracker.

I'm on Kubuntu 8.04 with latest Firefox 3.5b5pre and I see no problem when viewing either the example in comment 0 or comment 3. I also have an ATI card, though I don't use fglrx.

Assuming you're using 32-bit, it might be unique to x86_64.

Yes, 32-bit here, so that's a possibility.

Could be color correction / bad color profile.
Can you please set gfx.color_management.mode in about:config to 0 as test ?
(0: disabled, 1: color correction enabled, 2: only enabled for tagged images )

Setting gfx.color_management.mode to 0 and restarting the browser fixes the problem.

Given that forwarding X to another display doesn't exhibit the problem, I'm guessing it's not related to x86_64 but some peculiarity of my display or X server configuration that's confusing color management.

And indeed, if I set gfx.color_management.enabled in Firefox 3.0 to true, I can reproduce the problem with Firefox 3.0 as well. So presumably the difference with 3.5 is that the color management functionality is enabled by default.

*** Bug 490642 has been marked as a duplicate of this bug. ***

This bug is probably related to ATI's fglrx driver.
Can reproduce it with fglrx while using Xorg's radeon driver everything is fine.

Created an attachment (id=379090)
Xorg log, using Xorg's sis driver

I can reproduce this using Xorg's sis driver.

Ubuntu bug:
https://bugs.launchpad.net/bugs/386132

I'm having the same problem in Firefox 3.5 and 3.6 latest daily builds:
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1pre) Gecko/20090610 Ubuntu/9.04 (jaunty) Shiretoko/3.5pre
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2a1pre) Gecko/20090610 Ubuntu/9.04 (jaunty) Minefield/3.6a1pre

I'm on an x86_64 system using the fglrx drivers. I'm using driver version 8.612 which is the latest from ATI as of today.

When I use the workaround in comment #8, it works fine. I have images attached on launchpad and can add them here as well if that'll help.

see bug 418538 and bug 449681 for background.

ubuntu bug https://bugs.edge.launchpad.net/bugs/386132

Maybe related to bug 450283 or is that just about full colormanagement? ... confirming for now.

(In reply to comment #9)
> Setting gfx.color_management.mode to 0 and restarting the browser fixes the
> problem.

Do you experience this problem with gfx.color_management.mode = 2 or just 1?

I had this with the default setting of gfx.color_management.mode = 2 in FF3.5.

Can those who can reproduce this problem try Firefox 3.1 beta 3 to see if it shows up there. That should give us some idea if the problem is related to the rewrite or not.

I could even reproduce it in 3.0.x (see Bug 490642)

It's even worse when I toggle it in 3.0.11, every color is messed up, not just PNGs. It's a boolean in 3.0.x, so I can't set to 1 or 2, just true.

AMD just released Catalyst 9.6 (8.620) and i cannot see this bug with the new driver anymore.

Confirmed fixed with Ati 8.62 drivers.

pngcheck reports that the png.C2.png file has a gAMA and a cHRM
chunk:

  chunk gAMA at offset 0x00025, length 4: 0.45000
  chunk cHRM at offset 0x00035, length 32
    White x = 0.283 y = 0.298, Red x = 0.625 y = 0.34
    Green x = 0.285 y = 0.605, Blue x = 0.15 y = 0.065

Those data values seem to be OK.

We should perhaps be doing bogus profile detection on the generated profile? Or perhaps we should detect the bad values that we're using to generate from.

In the future, I plan on making an about:color-management page that should help diagnose these problems.

Closing https://bugzilla.redhat.com/show_bug.cgi?id=505709 as duplicate of this one, just so that it is not Ubuntu-only bug.

Apparently PNGs weren't the only format affected by this, but JPEGs are still suffering from this setting. That last bugzilla link was also for a JPEG report.
We had another bug submitted in Ubuntu for the JPEGs. Here's the relevant information:
This picture seems to be problematic:
http://einestages.spiegel.de/external/ShowTopicAlbumBackground/a4567/l19/l0/F.html#featuredEntry

Apparently, ATIs latest driver release either had a regression, or the last update was a fluke. The latest version (8.632) seems to have reverted whatever fixed the PNGs in 8.620.

(In reply to comment #25)

The embedded profile in that problematic JPEG claims to be the Hewlett-Packard sRGB profile. Here are the ICC header bytes according to ImageMagick's "identify -verbose":

  Profile-icc: 3144 bytes
0x00000000: 000c484c 696e6f02 1000006d 6e747252 47422058 ---HLino----mntrRGB
0x00000190: 595a2007 ce000200 09000600 31000061 6373704d XYZ ---------1--acsp
0x00000320: 53465400 00000049 45432073 52474200 00000000 MSFT----IEC sRGB----
0x000004b0: 00000000 00000100 00f6d600 01000000 00d32d48 --------------------
0x00000640: 50202000 00000000 00000000 00000000 00000000 HP ----------------
0x000007d0: 00000000 00000000 00000000 00000000 00000000 --------------------
0x00000960: 00000000 00000000 00001163 70727400 00015000 ------------cprt---P
0x00000af0: 00003364 65736300 00018400 00006c77 74707400 ---3desc-------lwtpt
0x00000c80: 0001f000 00001462 6b707400 00020400 00001472 --------bkpt--------
0x00000e10: 58595a00 00021800 00001467 58595a00 00022c00 rXYZ--------gXYZ---,
0x00000fa0: 00001462 58595a00 00024000 00001464 6d6e6400 ----bXYZ---@----dmnd
0x00001130: 00025400 00007064 6d646400 0002c400 00008876 ---T---pdmdd--------
0x000012c0: 75656400 00034c00 00008676 69657700 0003d400 vued---L----view----
0x00001450: 0000246c 756d6900 0003f800 0000146d 65617300 ---$lumi--------meas
0x000015e0: 00040c00 00002474 65636800 00043000 00000c72 -------$tech---0----
0x00001770: 54524300 00043c00 00080c67 54524300 00043c00 rTRC---<----gTRC---<
0x00001900: 00080c62 54524300 00043c00 00080c74 65787400 ----bTRC---<----text
0x00001a90: 00000043 6f707972 69676874 20286329 20313939 ----Copyright (c) 19
0x00001c20: 38204865 776c6574 742d5061 636b6172 6420436f 98 Hewlett-Packard C
0x00001db0: 6d70616e 79000064 65736300 00000000 00001273 ompany--desc--------
0x00001f40: 52474220 49454336 31393636 2d322e31 00000000 sRGB IEC61966-2.1---
0x000020d0: 00000000 00000012 73524742 20494543 36313936 ---------sRGB IEC619
0x00002260: 362d322e 31000000 00000000 00000000 00000000 66-2.1--------------
[snip]

I'm also seeing this bug with this image: http://llvm.org/img/DragonMedium.png (brown instead of blue-grey).
I posted some comments about my ICC profile here: https://bugzilla.mozilla.org/show_bug.cgi?id=450283#c11

The XFree86_DDC_EDID1_RAWDATA atom seems completely wrong on my system (ATI video card, fglrx 9.7 driver):

This is what my Xorg.0.log says:
(II) fglrx(0): Connected Display1: DFP on internal TMDS [tmds1]
(II) fglrx(0): Display1 EDID data ---------------------------
(II) fglrx(0): Manufacturer: SAM Model: 3e5 Serial#: 1415000626
(II) fglrx(0): Year: 2008 Week: 2
(II) fglrx(0): EDID Version: 1.3
(II) fglrx(0): Digital Display Input
(II) fglrx(0): Max Image Size [cm]: horiz.: 47 vert.: 30
(II) fglrx(0): Gamma: 2.20
(II) fglrx(0): DPMS capabilities: Off
(II) fglrx(0): Supported color encodings: RGB 4:4:4 YCrCb 4:4:4
(II) fglrx(0): First detailed timing is preferred mode
(II) fglrx(0): redX: 0.640 redY: 0.330 greenX: 0.300 greenY: 0.600
(II) fglrx(0): blueX: 0.150 blueY: 0.060 whiteX: 0.312 whiteY: 0.329

(II) fglrx(0): EDID (in hex):
(II) fglrx(0): 00ffffffffffff004c2de50332325754
(II) fglrx(0): 02120103802f1e782aee91a3544c9926
(II) fglrx(0): 0f5054bfef80b30081808140714f0101
(II) fglrx(0): 0101010101017c2e90a0601a1e403020
(II) fglrx(0): 3600da281100001a000000fd00384b1e
(II) fglrx(0): 510e000a202020202020000000fc0053
(II) fglrx(0): 796e634d61737465720a2020000000ff
(II) fglrx(0): 004831414b3530303030300a20200082
(II) fglrx(0): End of Display1 EDID data --------------------

And this is the atom:
XFree86_DDC_EDID1_RAWDATA(INTEGER) = 0, 0, 0, 0, 0, 0, 0, 0, 58, 32, 80, 114, 105, 110, 116, 105, 110, 103, 32, 68, 68, 67, 32, 103, 97, 116, 104, 101, 114, 101, 100, 32, 77, 111, 100, 101, 108, 105, 110, 101, 115, 58, 10, 0, 113, 79, 1, 1, 1, 1, 1, 1, 1, 1, 124, 46, -47, 0, 0, 0, 0, 0, 0, 0, 48, 36, 15, 2, 0, 0, 0, 0, 32, 118, 22, 2, 0, 0, 0, 0, 0, 118, 22, 2, 0, 0, 0, 0, 0, 0, 0, 0, 72, 0, 0, 0, -40, -48, 1, 0, -112, 6, 0, 0, -64, 6, 0, 0, -32, 6, 0, 0, 48, 7, 0, 0, 0, 0, 0, 0, 26, 4, 0, 0, 29, 4, 0,

Is this bug still an issue on Fx 3.5.x? I can't reproduce it on Fx 3.6.

(In reply to comment #29)
> Is this bug still an issue on Fx 3.5.x? I can't reproduce it on Fx 3.6.

I don't know, I switched to the open source xf86-video-ati driver, and it doesn't have the EDID atom...

This bug appears in 3.6.4 as well. I use colorprofiles created with a SpyderPRO hardware calibration device. All images are fine in IE8, opera10.5, safari4.0.5 and chrome4.1.2. I checked the images themselves by downloading them and using Photoshop.

That makes this behaviour specific to Firefox (3.6.4 here). I'm on WinXP x64.

Having the same issue in Firefox and Thunderbird with ATI FGLRX driver 10.8 on Kubuntu 10.04.1. It appears to be related to ATI drivers after I upgraded from 10.7 to 10.8 of the proprietary ATI driver, however the issue is not seen in KDE, nor the Konqueror and Ephipany browsers. Just Firefox and Thunderbird.

(In reply to comment #32)
> Having the same issue in Firefox and Thunderbird with ATI FGLRX driver 10.8 on
> Kubuntu 10.04.1. It appears to be related to ATI drivers after I upgraded from
> 10.7 to 10.8 of the proprietary ATI driver, however the issue is not seen in
> KDE, nor the Konqueror and Ephipany browsers. Just Firefox and Thunderbird.

Even the icons in Thunderbird toolbar exhibit the behavior, not just the Web page images in Firefox.

This issue still continues with Ati fglrx driver 10.9 and Firefox 3.6.10. Any news about that?

Created attachment 496089
Screenshot of the error with Firefox 4.0b7

I can still reproduce the problem with Xorg Server 1.9, Nouveau driver and Firefox 4.0b7. I'm attaching screenshot.

When I disable colormanagement setting gfx.color_management.mode = 0, colors are fine. Maybe I'll set this setting in the firefox distro package if this is not fixed.

Any update on this?

Same issue with Firefox 4, Aurora and nigthly.

The problem is only happening when using "Nouveau" driver (not with nvidia proprio driver).

The same with Firefox 5 and Thunderbird 3.1.11.

Running Ubuntu 11.04, graphic card Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03)

I can confirm this on Firefox Aurora (Firefox 9) and Firefox 7. It was also doing this previously so Firefox 6 and 8 are the same. The entire site is screwed up by this. I'm using Kubuntu 11.04 with proprietary nvidia drivers. Chrome works ok, no problem there.

Doesn't anybody know what is causing it? Are there any workarounds? Is this specific only for Linux users or should I worry that my customers see my website mangled up when using Firefox everywhere? Thanks

ok, I resolved it thanks to instructions on this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=629312

It's still a bug though because this is the default behavior, if it is "color profile broken" as suggested then why does it happen on vanilla installations? It's broken out of the box for users that are never going to go to bugzilla and tinker with advanced settings in Firefox.

*** This bug has been marked as a duplicate of bug 655637 ***