Closed Bug 395170 Opened 14 years ago Closed 14 years ago

with gfx.color_management turned ON grayscale images display badly


(Core :: Graphics, defect)

Not set





(Reporter: phiw2, Assigned: tor)





(3 files)

Attached image screenshot of URL field
user_pref("gfx.color_management.enabled", true);

Images in a webpage, or images displayed standalone turn to solid black on OS X, on Win a 4 band gradient.

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a8pre) Gecko/2007090523 Minefield/3.0a8pre
Attached image Screenshot of same page
Confirming on WinXP.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a8pre) Gecko/2007090504 Minefield/3.0a8pre
Blocks: colorsync
Flags: blocking1.9?
Attachment #279921 - Flags: review?(pavlov)
Duplicate of this bug: 395236
same behaviour on Vista

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9a8pre) Gecko/2007090604 Minefield/3.0a8pre ID:2007090604
The test file, which is a PNG 8-bit grayscale image, has a PNG iCCP chunk containing an Adobe printer GRAYXYZ profile, and PNG gAMA and cHRM chunks that contain sRGB values.  The decoder is supposed to ignore the gAMA and cHRM chunks if it is able to decode iCCP.
Right.  If you look at the code, there's a copy of the section I deleted inside a "if (!decoder->mTransform)" right above it.  Thus my guess that this was a result of a merge gone wrong at some point in the past.
I'm not a reviewer but the patch looks fine to me.  As you say it simply
fixes a botched merge.
Comment on attachment 279921 [details] [diff] [review]
mismerge of the cms patch at some point in its past

Quite safe change that will make grayscale PNGs display correctly with color management turned on.
Attachment #279921 - Flags: approval1.9?
Attachment #279921 - Flags: approval1.9? → approval1.9+
Checked in.
Closed: 14 years ago
Resolution: --- → FIXED
Flags: in-testsuite?
The xkcd link works for me, but the Phaistos Disc images at (e.g. show up as black rectangles. They work after setting gfx.color_management.enabled to false and restarting the browser.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a9pre) Gecko/2007102005 Minefield/3.0a9pre ID:2007102005
Resolution: FIXED → ---
Those work for me, but only with the 170kb large kodak_dc.icm
(In reply to comment #10)
Black rectangles on OS X... :-(
Please open new bugs for problems found long after the checkin of the original.

That said, the problem seems to lie in the images.  That particular image has an invalid looking cHRM chunk:

  chunk cHRM at offset 0x00035, length 32
    White x = 0 y = 0,  Red x = 0 y = 0
    Green x = 0 y = 0,  Blue x = 0 y = 0
sounds like the original bug here was fixed and that the rest isn't a bug?
Right, this should be marked FIXED again.  I will look into detecting and
rejecting erroneous cHRM chunks with zero white point within libpng.
Assignee: nobody → tor
Closed: 14 years ago14 years ago
Resolution: --- → FIXED
Libpng-1.2.23 will reject all-zero cHRM data.  The test images mentioned
in comment #10 will still not look quite right, though, because they have
bad gAMA chunks (containing 0xFFFF FFFF) as well, which will defeat the
anti-aliasing (all gray levels will be rendered as black).
Depends on: 406554
You need to log in before you can comment on or make changes to this bug.