Closed
Bug 490537
Opened 15 years ago
Closed 13 years ago
Colors in some PNG images are severely wrong
Categories
(Core :: Graphics: Color Management, defect)
Tracking
()
RESOLVED
DUPLICATE
of bug 655637
People
(Reporter: tack-bugzilla, Unassigned)
References
Details
(Keywords: regression)
Attachments
(5 files)
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•15 years ago
|
||
Reporter | ||
Comment 2•15 years ago
|
||
The image shown in this screenshot is attachment #3 [details] [diff] [review].
Reporter | ||
Comment 3•15 years ago
|
||
Reporter | ||
Comment 4•15 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•15 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•15 years ago
|
Component: General → ImageLib
Product: Firefox → Core
QA Contact: general → imagelib
Version: 3.5 Branch → 1.9.1 Branch
Reporter | ||
Comment 6•15 years ago
|
||
Assuming you're using 32-bit, it might be unique to x86_64.
Comment 8•15 years ago
|
||
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•15 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.
Updated•15 years ago
|
Component: ImageLib → GFX: Color Management
QA Contact: imagelib → color-management
Comment 11•15 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.
Comment 12•15 years ago
|
||
I can reproduce this using Xorg's sis driver.
Comment 13•15 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•15 years ago
|
||
see bug 418538 and bug 449681 for background.
Comment 15•15 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•15 years ago
|
||
I had this with the default setting of gfx.color_management.mode = 2 in FF3.5.
Comment 17•15 years ago
|
||
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•15 years ago
|
||
I could even reproduce it in 3.0.x (see Bug 490642)
Comment 19•15 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•15 years ago
|
||
AMD just released Catalyst 9.6 (8.620) and i cannot see this bug with the new driver anymore.
Comment 21•15 years ago
|
||
Confirmed fixed with Ati 8.62 drivers.
Comment 22•15 years ago
|
||
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.
Comment 23•15 years ago
|
||
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•15 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•15 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.
Comment 26•15 years ago
|
||
(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•15 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•15 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,
Comment 29•14 years ago
|
||
Is this bug still an issue on Fx 3.5.x? I can't reproduce it on Fx 3.6.
Comment 30•14 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...
See Also: → https://launchpad.net/bugs/386132
Comment 31•14 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•14 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•14 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•14 years ago
|
||
This issue still continues with Ati fglrx driver 10.9 and Firefox 3.6.10. Any news about that?
Comment 35•14 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.
Comment 36•13 years ago
|
||
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•13 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•13 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•13 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.
Updated•13 years ago
|
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•