Colors in some PNG images are severely wrong

RESOLVED DUPLICATE of bug 655637

Status

()

--
major
RESOLVED DUPLICATE of bug 655637
10 years ago
7 years ago

People

(Reporter: tack-bugzilla, Unassigned)

Tracking

({regression})

1.9.1 Branch
x86_64
Linux
regression
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(5 attachments)

(Reporter)

Description

10 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.7) Gecko/2009030423 Ubuntu/8.04 (hardy) Firefox/3.0.7
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1b5pre) Gecko/20090428 Shiretoko/3.5b5pre

Some (but not all) PNG images are not displayed properly with 3.5 nightly, whereas 3.0.x renders them fine.  The colors are not just slightly wrong (e.g. wrong gamma).

For example: http://www.libpng.org/pub/png/book/figs/png.C2.png

Reproduceable even with a new profile.  Will attach screenshots.

Reproducible: Always
(Reporter)

Comment 1

10 years ago
(Reporter)

Comment 2

10 years ago
The image shown in this screenshot is attachment #3 [details] [diff] [review].
(Reporter)

Comment 3

10 years ago
(Reporter)

Comment 4

10 years ago
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.

Comment 5

10 years ago
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.
Keywords: regression
Version: unspecified → 3.5 Branch

Updated

10 years ago
Component: General → ImageLib
Product: Firefox → Core
QA Contact: general → imagelib
Version: 3.5 Branch → 1.9.1 Branch
(Reporter)

Comment 6

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

Comment 7

10 years ago
Yes, 32-bit here, so that's a possibility.
Hardware: x86 → x86_64
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 )
(Reporter)

Comment 9

10 years ago
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.
Component: ImageLib → GFX: Color Management
QA Contact: imagelib → color-management
Blocks: 490642

Updated

10 years ago
Duplicate of this bug: 490642

Comment 11

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

Updated

10 years ago
No longer blocks: 490642

Comment 12

10 years ago
I can reproduce this using Xorg's sis driver.

Comment 13

10 years ago
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.

Comment 14

10 years ago
see bug 418538 and bug 449681 for background.

Comment 15

10 years ago
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?
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 16

10 years ago
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.

Comment 18

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

Comment 19

10 years ago
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.

Comment 20

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

Comment 21

10 years ago
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.

Comment 24

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

Comment 25

10 years ago
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]

Comment 27

10 years ago
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

Comment 28

10 years ago
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.

Comment 30

9 years ago
(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...

Comment 31

9 years ago
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.

Comment 32

9 years ago
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.

Comment 33

9 years ago
(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.

Comment 34

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

Comment 35

8 years ago
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).

Comment 37

8 years ago
Marco Biscaro added the following comment to Launchpad bug report 386132:

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)

-- 
http://launchpad.net/bugs/386132

Comment 38

8 years ago
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

Comment 39

8 years ago
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.
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 655637
You need to log in before you can comment on or make changes to this bug.