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)

defect
Not set
normal

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
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.
Here the requested image.

If i turn color correction off, the site is displayed correctly.
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
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.
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".
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?
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.
Here's my screenshot.  There are faint differences between sRGB and untagged, but not as pronounced as yours.
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
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
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.
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...
(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
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.
> > 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.
Correcting MIME type as Bugzilla didn't detect it properly...
Attachment #658019 - Attachment is obsolete: true
Attachment #658020 - Attachment mime type: text/plain → text/html
(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.
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
Branch should also be changed from 1.9.2 to trunk (I can reproduce it on nightly, obviously).
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.
I've just switched to OS X 10.8 and I don't see the issue here.
OK, if I check colors using DigitalColor Meter app I see colors don't fully match, though it's not visible using bare eyes.
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
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
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.
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.
(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)
@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)
(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
(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).
And how can I check if the profile is actually at fault?
(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
(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?
Can you provide the actual "continue" button PNG?
Flags: needinfo?(elbart)
Attached file intel_pngs.zip
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)
This is similar to the page that used to be at glennrp.net, per comment #7
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.
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)
Thanks for working on this, Glenn!
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)
Keywords: footprint, perf
Version: 1.9.2 Branch → Trunk
Summary: Image displays incorrect with wrong color (png) → Image displays incorrect with wrong color (PNG sRGB doesn't match)
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)
Add checkin message
Attachment #8553704 - Attachment is obsolete: true
Attachment #8553704 - Flags: review?(jmuizelaar)
Attachment #8553705 - Flags: review?(jmuizelaar)
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 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-
Relax tolerance in gamma and chromaticity that will be recognized as sRGB.
Attachment #8553705 - Attachment is obsolete: true
Attached file png_cms_test_page.html (obsolete) —
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.
I'll have to redo the tests.  The column labeled "sRGB" actually contains untagged images.
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
Depends on: 449681
See Also: → 1197593
See Also: → 1135380
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
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
..ADD:
And no
   setting gfx.color_management.mode to 1
does not do the trick
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)
(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.

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)
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.