395170 - with gfx.color_management turned ON grayscale images display badly

Status: RESOLVED FIXED

(Core :: Graphics, defect)

Description

[philippe (part-time)]

Attachment: 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

Comment 1

[Edward Asquith]

Attachment: 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

Comment 2

[tor]

Attachment: mismerge of the cms patch at some point in its past

Comment 4

[Barrie North]

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

Comment 5

[Glenn Randers-Pehrson]

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.

Comment 6

[tor]

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.

Comment 7

[Glenn Randers-Pehrson]

I'm not a reviewer but the patch looks fine to me.  As you say it simply
fixes a botched merge.

Comment 8

[tor]

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.

Comment 9

[tor]

Checked in.

Comment 10

[Justin Kerk]

The xkcd link works for me, but the Phaistos Disc images at http://en.wikipedia.org/wiki/Arkalochori_Axe (e.g. http://en.wikipedia.org/wiki/Image:Phaistos_glyph_39.png) 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

Comment 11

[Peter van der Woude [:Peter6]]

Those work for me, but only with the 170kb large kodak_dc.icm

Comment 12

[philippe (part-time)]

(In reply to comment #10)
Black rectangles on OS X... :-(

Comment 13

[tor]

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

Comment 14

[Stuart Parmenter]

sounds like the original bug here was fixed and that the rest isn't a bug?

Comment 15

[Glenn Randers-Pehrson]

Right, this should be marked FIXED again.  I will look into detecting and
rejecting erroneous cHRM chunks with zero white point within libpng.

Comment 16

[Reed Loden [:reed]]

Re-resolving.

Comment 17

[Glenn Randers-Pehrson]

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