Closed
Bug 621474
Opened 13 years ago
Closed 2 years ago
Image displays incorrect with wrong color (PNG sRGB doesn't match)
Categories
(Core :: Graphics: Color Management, defect)
Core
Graphics: Color Management
Tracking
()
RESOLVED
INACTIVE
People
(Reporter: mail, Unassigned)
References
()
Details
(Keywords: memory-footprint, perf)
Attachments
(16 files, 10 obsolete files)
370 bytes,
image/png
|
Details | |
137.25 KB,
image/png
|
Details | |
22.74 KB,
image/png
|
Details | |
27.13 KB,
image/png
|
Details | |
24.20 KB,
image/png
|
Details | |
33.90 KB,
image/png
|
Details | |
8.87 KB,
text/html
|
Details | |
11.54 KB,
application/force-download
|
Details | |
8.07 KB,
text/html
|
Details | |
4.92 KB,
patch
|
Details | Diff | Splinter Review | |
143.17 KB,
text/html
|
Details | |
52.28 KB,
image/png
|
Details | |
52.58 KB,
image/png
|
Details | |
53.80 KB,
image/png
|
Details | |
53.04 KB,
image/png
|
Details | |
43.42 KB,
image/png
|
Details |
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US) AppleWebKit/534.10 (KHTML, like Gecko) Chrome/8.0.552.224 Safari/534.10 Build Identifier: The background image (http://nicole.im/files/style/bg1.png) on the site(http://nicole.im/zvdf/)has a wrong color in Firefox. This appears in Firefox version 3.6.13 and 4.0b8. Chrome displays the image correct and if I download the image, my image viewer "Eye of Gnome" displays it correct too. I have tested this with several different systems. (Windows/Linux) Reproducible: Always Steps to Reproduce: 1.Open the Image or the Site with Firefox Actual Results: The image displays incorrect with wrong color Expected Results: The image should displays correct with the right colors
Reporter | ||
Comment 1•13 years ago
|
||
Comment 2•13 years ago
|
||
Please provide a screenshot from that page, this looks ok with Seamonkey trunk, FF3.6.13, OPera10.X and IE8 on my system Firefox is doing Image color correction while Chrome isn't doing that (missing feature). Enter "about:config" as URl without the "" in Firefox, confirm the warning, enter "color_" in the top filter bar and change gfx.color_management.mode to 0 (default is 2) and test your image again after a FF restart.
Reporter | ||
Comment 3•13 years ago
|
||
Here the requested image. If i turn color correction off, the site is displayed correctly.
Comment 4•13 years ago
|
||
Your color profile for your monitor must be broken in that case. It's not a problem with wrong color information in the image because it looks ok on my win32 system. You could use an image viewer that supports color correction to compare the results : http://en.wikipedia.org/wiki/Linux_color_management#A_list_of_Linux_color-managed_applications You could also remove the color profile from that PNG with an image editor that supports that but that wouldn't solve the problem.
Component: General → GFX: Color Management
Product: Firefox → Core
QA Contact: general → color-management
Version: unspecified → 1.9.2 Branch
Reporter | ||
Comment 5•13 years ago
|
||
Weird because I've tested this with different systems. One Notebook with Fedora, another Notebook with Archlinux. All with the same results. One friend told me that he has the problem with his Windows system too. Another friend has send me an screenshot how the site is rendered on his Windows system. The screenshot shows no problems. I opened the image with different programs. Gimp, Krita and Incscape are showing the image correct. Gimp and Krita tells me that the image don't have an color profile. The problem exist for me now since 1 or 2 months. Some day it didn't displayed correct anymore. I am not sure but i think the problem started after an update.
Comment 6•13 years ago
|
||
The image, which has 1x612 dimensions, has the following chunks: Reading IHDR chunk, length = 13. Reading sRGB chunk, length = 1. Reading bKGD chunk, length = 6. Reading pHYs chunk, length = 9. Reading tIME chunk, length = 7. Reading IDAT chunk, length = 242. Reading IEND chunk, length = 0. The only color-related chunk is sRGB. The image has png colortype 6 (RGBA) but all of the pixels are opaque. Without a screenshot or something, it's not easy to know what you are actually seeing that is "wrong".
Comment 7•13 years ago
|
||
I posted some test images at http://glennrp.net/bug621474 as RGBA and RGB PNGs, with and without the sRGB chunk. I widened the image from 1 pixel wide to 100 for easier viewing and clicking. All four images look the same to me, with Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101206 Ubuntu/10.04 (lucid) Firefox/3.6.13 Mathias, would you post a screenshot of how this page looks to you?
Reporter | ||
Comment 8•13 years ago
|
||
OK. Here how it looks to me in "Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101230 Firefox/3.6.13" and in "Mozilla/5.0 (X11; Linux x86_64; rv:2.0b8) Gecko/20100101 Firefox/4.0b8" on archlinux.
Comment 9•13 years ago
|
||
Here's my screenshot. There are faint differences between sRGB and untagged, but not as pronounced as yours.
Comment 10•13 years ago
|
||
I widened the images a little more and added some markup to remove the space between the images in the table, to make the differences easier to see. I'll take this bug, but I think it might just turn out to be differences in the monitor color profiles.
Assignee: nobody → glennrp+bmo
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 11•13 years ago
|
||
I am still seeing this bug in: Build identifier: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20100101 Firefox/7.0.1 Iceweasel/7.0.1 Here is a screenshot (I can't attach it on the web interface for some reason) http://i.imgur.com/J6krG.png
Comment 12•13 years ago
|
||
I can verify that this is, in fact, occurring. http://imgur.com/8vrAb On the left is Firefox, displaying the PNG used to cut off the corner of a div too lightly, and on the right is Opera, which is displaying it correctly. I have tested this in Chrome as well as Chromium. The CSS of the page has the background #252525, and I designed the image to match this. When I noticed the color discrepancy in Firefox, I took a screenshot. The Gimp is reporting that Firefox is displaying the grey part of the PNG file to be #292929, which is too light.
Comment 13•12 years ago
|
||
I can see the bug, too... Look at: http://partycypacjaobywatelska.pl/ I'll attach screenshots in Chrome and Firefox, the latter looks ugly as image colors don't match background ones...
Comment 14•12 years ago
|
||
Comment 15•12 years ago
|
||
(In reply to Michał Z. Gołębiowski from comment #14) > Created attachment 657803 [details] > Firefox screenshot - colors don't match I'm seeing a perfect match when viewing http://partycypacjaobywatelska.pl using Firefox 15.0 on Ubuntu 12.04 Here are my color_management settings from about:config: gfx.color_management.display_profile; gfx.color_management.enablev4;false gfx.color_management.mode;2 gfx.color_management.rendering_intent;0
Comment 16•12 years ago
|
||
Whether his color correction settings are right or wrong, the end result is that he's now going to have to tell anyone who visits his site to adjust their color correction settings in order to view the site properly. Why Mozilla has determined that we must have color correction on png files is beyond me. It was a bad move, I can see it for jpgs, but pngs are used for layout. What are we to do? Make sure every person who views his site from a firefox browser reads this bug report first so they know their computers are messed up? I think firefox should not color-correct png files.
Comment 17•12 years ago
|
||
> > Firefox screenshot - colors don't match
> I'm seeing a perfect match when viewing
> http://partycypacjaobywatelska.pl
I'm sorry, this is a production site so I had to fix it and I used transparent PNGs (no idea why they weren't transparent from the beginning...). Anyway, I'm attaching a sort-of minimal example showing the issue.
Please, check again.
Comment 18•12 years ago
|
||
Correcting MIME type as Bugzilla didn't detect it properly...
Attachment #658019 -
Attachment is obsolete: true
Updated•12 years ago
|
Attachment #658020 -
Attachment mime type: text/plain → text/html
Comment 19•12 years ago
|
||
(In reply to Glenn Randers-Pehrson from comment #15) > Here are my color_management settings from about:config: > gfx.color_management.display_profile; > gfx.color_management.enablev4;false > gfx.color_management.mode;2 > gfx.color_management.rendering_intent;0 BTW, my color settings in about:config are identical.
Comment 20•12 years ago
|
||
In attachment 658020 [details] the main color of the image and the
HTML background don't match.
The HTML contains
<body style="background-color: #00DF00;">
According to ImageMagick "identify -verbose index.png",
the PNG image contains
Colors: 253
Histogram:
24812: ( 0,224, 0,255) #00E000 srgba(0,224,0,1)
: [251 colors with few instances, for antialiasing]
2488: (255,255,255,255) #FFFFFF white
Rendering intent: Perceptual
Properties:
Comment: Created with GIMP
png:gAMA : gamma=0.45454544 (See Gamma, above)
png:IHDR.bit_depth : 8
png:IHDR.color_type : 6 (RGBA)
png:IHDR.interlace_method: 0 (Not interlaced)
png:IHDR.width,height : 360, 80
png:pHYs : x_res=2835, y_res=2835, units=1
png:sRGB : intent=0 (Perceptual Intent)
Firefox 15.0 is incorrectly displaying the image with the main color (#00E000)
a visibly brighter green than the background (#00DF00).
Chrome 21.0.1180.89 displays the image with the main color visibly indistinguishable
from the page background.
I created an image with just those two colors and noted that they are
visually indistinguishable to me, so I agree that the Firefox-15.0 rendering
is incorrect.
Status: NEW → ASSIGNED
Comment 21•12 years ago
|
||
Branch should also be changed from 1.9.2 to trunk (I can reproduce it on nightly, obviously).
Comment 22•12 years ago
|
||
Looking at http://www.libpng.org/pub/png/png-gammatest.html which was mentioned in another bug or two, it's clear that PNG images containing the sRGB chunk are slightly darker than they should be, while images containing the gAMA chunk wih gamma=1/2.2, but no sRGB chunk, match the background exactly. I think this means that HTML colors are being displayed with gamma=1/2.2 instead of precisely sRGB. See bug #569814 and bug #454688. It seems that the faint differences observed in those bugs, and fixed, has reverted around Firefox 12.0, I'm not sure whether there is a bug in the PNG decoder or in the HTML color renderer, but it looks as though it's the latter.
Comment 23•12 years ago
|
||
I've just switched to OS X 10.8 and I don't see the issue here.
Comment 24•12 years ago
|
||
OK, if I check colors using DigitalColor Meter app I see colors don't fully match, though it's not visible using bare eyes.
Comment 26•11 years ago
|
||
Glenn, From my experiments, I believe this bug is Linux-only; when testing with the same tests, I can not reproduce it with Firefox 25 under Windows XP SP3. My Linux is Kubuntu 13.10 distribution KDE 4.11.2 Linux kernel 3.11.0-13-generic x86_64 (64bits) Qt: 4.8.4. I develop CSS tests, support images for the tests and reftests and, IMO, this color problem only appeared recently (around Firefox 23 or so). My gfx.color_management.* settings in about:config are: gfx.color_management.display_profile : gfx.color_management.enablev4 : false gfx.color_management.mode : 2 gfx.color_management.rendering_intent : 0 These 10 tests when viewed in Firefox 25 under Linux show not uniform green color inside the filled green square: http://test.csswg.org/source/contributors/gtalbot/submitted/border-image-017.htm (and also 018, 019, 020) http://test.csswg.org/source/contributors/gtalbot/submitted/border-image-slice-001.htm (and border-image-slice-002) http://test.csswg.org/source/contributors/gtalbot/submitted/inherit-static-offset-001.htm (and also 002, 003) and its related reftest: http://test.csswg.org/source/contributors/gtalbot/submitted/reference/ref-filled-green-100px-square.xht ----------- 1 Test: http://www.gtalbot.org/BrowserBugsSection/css21testsuite/line-height-129.xht and its reftest: http://www.gtalbot.org/BrowserBugsSection/css21testsuite/reference/ref-filled-green-100px-square.xht I've asked other Linux Ubuntu and Kubuntu users if the green color of filled squares of tests and reftests match and their answers vary for unknown reasons. Glenn, let me know if you want more info from me. Gérard
Comment 27•10 years ago
|
||
I've come across this bug today. If I save my PNG with gamma information the color is displayed correctly. If I don't save the gamma information to my PNG file the color is brightened up. Chrome doesn't display the color wrongly. Gamma correcting the color should be off for non existent gamma profiles in PNG images. Cheers, Martin
Comment 29•10 years ago
|
||
This behavior still exists in Nightly running on Ubuntu 14.04LTS. In a duplicate bug, bug #982065, I observed that color #0073C6 is displayed as #0071C2 (a very faint difference) in images that have the sRGB chunk or have an sRGB ICC profile. In a PNG with no color chunks, it is displayed the same as the background, #0073C6.
Comment 30•10 years ago
|
||
I discovered this bug today. In Windows 7 on one machine, and in Ubuntu 13.10 on the other (but not Windows 7, for some reason...). The test of comment 22 has the last two rows of each group showing the squares on the inside. Also, on http://downloadcenter.intel.com/default.aspx?lang=eng the blue buttons are looking wrong: http://i.imgur.com/XV8xuJW.png The "misbehaving" image for the buttons (element_tops_bottoms_etc.png) has "SRGB Rendering: Perceptual" set. Please let me know if you need more info or data (monitor profiles etc.). Regarding regression-range: Last good nightly: 2008-09-11 First bad nightly: 2008-09-12 http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2008-09-10&enddate=2008-09-12 I think the switch to the new color-correction-system was in that timeframe.
Comment 31•10 years ago
|
||
(In reply to Elbart from comment #30) > I discovered this bug today. > In Windows 7 on one machine, and in Ubuntu 13.10 on the other (but not > Windows 7, for some reason...). On the affected machine, Win7 is using a specific color-profile for my monitor out-of-the-box, and on the unaffected machine it's not. When doing the Windows-built-in calibration on the affected machine, it's creating a profile called "sRGB display profile with display hardware configuration data derived from calibartion" which doesn't show the wrong colors in Firefox. Does that mean the color profile of my monitor is not properly supported by Firefox or broken in general? How can I test either case?
Flags: needinfo?(glennrp+bmo)
Comment 32•10 years ago
|
||
@Elbart, please try setting gfx.color_management.mode to 1 in about:config. If you do that, then the PNG and the surrounding HTML/CSS elements should all be getting the same color management treatment. With the default value, 2, the images get color managed but other elements don't.
Flags: needinfo?(glennrp+bmo)
Comment 33•10 years ago
|
||
(In reply to Glenn Randers-Pehrson from comment #32) > @Elbart, please try setting gfx.color_management.mode to 1 in about:config. > If you do that, then the PNG and the surrounding HTML/CSS elements should > all be getting the same color management treatment. With the default value, > 2, the images get color managed but other elements don't. Yes, that "fixes" the problem on the Intel-site, as shown in the linked image in comment 30. Maybe a mail to Intel to tell them to fix the used images (namely button-container-repeat.png) would help. But the problem with the PNG-test remains, and I found another test it's failing with gfx.color_management.mode;2: "How does your browser interpret untagged images and page elements?" on http://cameratico.com/tools/web-browser-color-management-test/ In my case: http://i.imgur.com/1KEVc2C.png
Comment 34•10 years ago
|
||
(In reply to Elbart from comment #33) > and I found another test it's > failing with gfx.color_management.mode;2: > > "How does your browser interpret untagged images and page elements?" > on > http://cameratico.com/tools/web-browser-color-management-test/ > > In my case: http://i.imgur.com/1KEVc2C.png With gfx.color_management.mode;2 only tagged images are color managed, so this is expected. It's a somewhat conservative choice and I don't think it's very intuitive, but IIRC we use gfx.color_management.mode;2 by default *because* some systems ship with broken color profiles (so for those users, at least the rest of the browser would look okay).
Comment 35•10 years ago
|
||
And how can I check if the profile is actually at fault?
Comment 36•10 years ago
|
||
(In reply to Elbart from comment #35) > And how can I check if the profile is actually at fault? Since the problem disappears if you go to build:config and set gfx.color_management.mode to 1 (as in comment #32) your profile is most likely OK. The fix is to not use gfx.color_management.mode==2 which instructs Mozilla to display images differently from the background elements. I thought the default "2" was to be a temporary thing but it's been well over a decade now. See bug #53597 for history. Note that non-image elements are using gamma=1/2.2 not sRGB, so sRGB images don't match the background exactly. You should be able to make the images match exactly by removing the sRGB chunk or iCCP chunk that contains an sRGB profile. You could use a gAMA 45455 chunk instead, until the gfx.color_management.mode default is changed. I can't guarantee that those PNGs will match the background on other browsers, though.
See Also: → 53597
Comment 37•10 years ago
|
||
(In reply to Glenn Randers-Pehrson from comment #36) > I can't guarantee that those PNGs will match the background > on other browsers, though. Regarding the Intel-site, I'd like to know what's the correct behavior: http://imgur.com/a/WKDtC "Mode 1", "Mode 2" and Chrome are applying color correction (see the PDF-image under "Recent Content"), "Mode 0" is without color correction. Yet the "Continue"-button is being treated differently. Mode 2 only applies cc to the ends (the image with sRGB-chunk), and Chrome doesn't apply any color correction. Which one is the correct one?
Comment 39•10 years ago
|
||
They changed the design in the meantime, but I found the images. element_tops_bottoms_etc.png for the round sites, and button-container-repeat.png was used as background for the mid-section.
Flags: needinfo?(elbart)
Comment 40•9 years ago
|
||
This is similar to the page that used to be at glennrp.net, per comment #7
Comment 42•9 years ago
|
||
Handle PNG images that are tagged with the sRGB chunk or with the exact values of gamma and chromaticity corresponding to sRGB as if they were untagged, when CMSMode is "TaggedOnly". This will make them match HTML sRGB colors, and will reduce memory and CPU usage.
Comment 43•9 years ago
|
||
The v00 patch works fine locally. It's possible that some reftests will need to change slightly. Time for a try run.
Flags: needinfo?(ryanvm)
Comment 44•9 years ago
|
||
Thanks for working on this, Glenn!
Comment 45•9 years ago
|
||
https://treeherder.mozilla.org/ui/#/jobs?repo=try&revision=29ca9b62e772
Flags: needinfo?(ryanvm)
Comment 46•9 years ago
|
||
Comment on attachment 8538971 [details] [diff] [review] v00-621474-handle-sRGB-PNG-as-untagged Try is green including the reftests. r?
Attachment #8538971 -
Flags: review?(jmuizelaar)
Updated•9 years ago
|
Updated•9 years ago
|
Summary: Image displays incorrect with wrong color (png) → Image displays incorrect with wrong color (PNG sRGB doesn't match)
Comment 47•9 years ago
|
||
Rebased (only the hunk offsets changed) and added checkin message.
Attachment #8538971 -
Attachment is obsolete: true
Attachment #8538971 -
Flags: review?(jmuizelaar)
Attachment #8553704 -
Flags: review?(jmuizelaar)
Comment 48•9 years ago
|
||
Add checkin message
Attachment #8553704 -
Attachment is obsolete: true
Attachment #8553704 -
Flags: review?(jmuizelaar)
Attachment #8553705 -
Flags: review?(jmuizelaar)
Comment 49•9 years ago
|
||
I'm not sure we want to do this. If we're going to change our behaviour I'd rather we move in the direction of getting the same behaviour from different browsers. From the looks of it, this makes it so that we're different from old FF and still different from other browsers. I don't think there's a summary of the different behaviors anywhere, so that might be a good place to start. It also looks like this patch causes a behaviour difference when an image is tagged as sRGB vs having an sRGB profile embedded. This would likely be surprising to authors. That being said, this is an interesting approach and still might be worth doing.
Comment 50•9 years ago
|
||
Comment on attachment 8553705 [details] [diff] [review] v01-621474-handle-sRGB-PNG-as-untagged Review of attachment 8553705 [details] [diff] [review]: ----------------------------------------------------------------- r- this until the issues I described below are addressed.
Attachment #8553705 -
Flags: review?(jmuizelaar) → review-
Comment 51•9 years ago
|
||
Relax tolerance in gamma and chromaticity that will be recognized as sRGB.
Attachment #8553705 -
Attachment is obsolete: true
Comment 52•9 years ago
|
||
Test page with unmarked, gamma-only, srgb-only, chrm-only, gamma+chrm, iccp images (all with sRGB pixels), and an image with gamma=1.0 and linear pixels, in various colors.
Comment 53•9 years ago
|
||
Comment 54•9 years ago
|
||
Comment 55•9 years ago
|
||
Comment 56•9 years ago
|
||
Comment 57•9 years ago
|
||
Comment 58•9 years ago
|
||
I'll have to redo the tests. The column labeled "sRGB" actually contains untagged images.
Comment 59•9 years ago
|
||
Attachment #8558185 -
Attachment is obsolete: true
Attachment #8558186 -
Attachment is obsolete: true
Attachment #8558188 -
Attachment is obsolete: true
Attachment #8558189 -
Attachment is obsolete: true
Attachment #8558191 -
Attachment is obsolete: true
Attachment #8558192 -
Attachment is obsolete: true
Comment 60•9 years ago
|
||
Comment 61•9 years ago
|
||
Comment 62•9 years ago
|
||
Comment 63•9 years ago
|
||
Comment 64•9 years ago
|
||
Comment 65•8 years ago
|
||
The issue is still there, e.g. with a PNG created with simple Bitmap Save from .NET (Or created in Paint) I wrote a bit more on it here with examples, and quite small 150b test-files. Both FF and Chrome are affected, but IE/Edge are NOT affected. http://eskerahn.dk/wordpress/?p=1566
Comment 66•8 years ago
|
||
That's a different issue, namely your downsizing procedure inserting a bad ICC profile. See https://bugzilla.mozilla.org/show_bug.cgi?id=1135380#c9
Comment 67•8 years ago
|
||
..ADD: And no setting gfx.color_management.mode to 1 does not do the trick
Comment 68•7 years ago
|
||
https://drive.google.com/file/d/0B_yEbP1sy9ScX09CYS1UaGxyWWs/view?usp=sharing That's a good example of wrong colors on firefox. Steps: - Open the photo on firefox - Open the photo on any other browser (tested with Chrome, IE, Safari latest versions)
Comment 69•7 years ago
|
||
(In reply to straris from comment #68) > https://drive.google.com/file/d/0B_yEbP1sy9ScX09CYS1UaGxyWWs/ > view?usp=sharing > That's a good example of wrong colors on firefox. > Steps: > - Open the photo on firefox > - Open the photo on any other browser (tested with Chrome, IE, Safari latest > versions) The test file is a JPEG with a large ICC profile, and has nothing to do with this PNG bug.
Comment 70•2 years ago
|
||
The bug assignee didn't login in Bugzilla in the last 7 months.
:aosmond, could you have a look please?
For more information, please visit auto_nag documentation.
Assignee: glennrp+bmo → nobody
Status: ASSIGNED → NEW
Flags: needinfo?(aosmond)
Updated•2 years ago
|
Status: NEW → RESOLVED
Closed: 2 years ago
Flags: needinfo?(aosmond)
Resolution: --- → INACTIVE
You need to log in
before you can comment on or make changes to this bug.
Description
•