possible bug converting PNG from linear gray to nonlinear gray

[fmw42]

IM 6.9.0.0 Q16 Mac OSX Snow Leopard

Input image:
http://www.brandnex.com/wristbands/test ... d_none.png

identify -verbose shows it as linear
Gamma: 1
Background color: gray(255)
Border color: gray(223)
Matte color: gray(189)
Transparent color: gray(0)
Interlace: None
Intensity: Rec709Luminance


But my attempts to change the colorspace to non-linear (gamma=0.4545) do not work. None of the following work:

Code: Select all

convert hw_180_wristband_none.png -colorspace gray tmp1.png

convert hw_180_wristband_none.png -colorspace rec709luma tmp2.png

convert hw_180_wristband_none.png -grayscale rec709luma tmp3.png

convert hw_180_wristband_none.png -colorspace sRGB tmp4.png

Note convert the same way to JPG works fine and produces gamma=0.4545. But strangely the darkness/lightness of the gray is unchanged. So I think the original PNG was properly non-linear, but the labels for gamma and intensity may be mislabeled(?).

convert hw_180_wristband_none.png -colorspace gray hw_180_wristband_none.jpg



Reference to topic viewtopic.php?f=1&t=26575#p117142

[glennrp]

There is no "gAMA" chunk in the input file. ImageMagick is inserting "gamma = 1"
because it detects that the image is grayscale.

glenn.rp> pngcheck -v hw*
File: hw_180_wristband_none.png (20221 bytes)
chunk IHDR at offset 0x0000c, length 13
320 x 240 image, 8-bit grayscale, non-interlaced
chunk cHRM at offset 0x00025, length 32
White x = 0.3127 y = 0.329, Red x = 0.64 y = 0.33
Green x = 0.3 y = 0.6, Blue x = 0.15 y = 0.06
chunk bKGD at offset 0x00051, length 2
gray = 0x00ff
chunk oFFs at offset 0x0005f, length 9: 4254827370x18 pixels offset
chunk pHYs at offset 0x00074, length 9: 100x100 pixels/unit (1:1)
chunk tEXt at offset 0x00089, length 70, keyword: Raw profile type APP12
chunk vpAg at offset 0x000db, length 9
unknown private, ancillary, safe-to-copy chunk
chunk IDAT at offset 0x000f0, length 19863
zlib: deflated, 32K window, maximum compression
chunk tEXt at offset 0x04e93, length 37, keyword: date:create
chunk tEXt at offset 0x04ec4, length 37, keyword: date:modify
chunk IEND at offset 0x04ef5, length 0
No errors detected in hw_180_wristband_none.png (11 chunks, 73.7% compression

It appears that the original image was created with ImageMagick (no other software
adds a vpAg chunk).

The "APP12" chunk is a JPEG thing, not understood by the PNG decoder, so it's just
handled as textual data.

It contains
0000040 A P P 1 2 \n 1 5 \n 4
0000060 4 7 5 6 3 6 b 7 9 0 0 0 1 0 0 0
0000100 4 0 0 0 0 0 0 3 c 0 0 0 0 \n

I believe it conveys color information to the JPEG decoder.
[EDIT] No that's wrong. It contains the "quality" of JPEG compression.

[fmw42]

It appears that the original image was created with ImageMagick (no other software
adds a vpAg chunk).

If IM created the original file, then the question is why there was no "gAMA" chunk specified. Is this a bug? Could it have come from an earlier version of IM that was at the time buggy?

Nevertheless is it not a bug if one cannot convert it to non-linear gray?

[fmw42]

The issue is that the OP said the files were converted from some JPG files. Perhaps the issue is with the original jpg and its conversion to PNG. The original JPG could have been linear gray. We really do not know until he responds to my request for the original jpg and his command to process it to PNG.

[glennrp]

I verified that the PNG reader is operating differently from the JPEG and PNM
readers when presented with an all-gray image:

hw20.ppm PPM 320x240 320x240+0+0 8-bit sRGB 230KB 0.000u 0:00.000
hw180.pgm[1] PGM 320x240 320x240+0+0 8-bit Grayscale Gray 76.8KB 0.000u 0:00.000
hw20.jpg[2] JPEG 320x240 320x240+0+0 8-bit sRGB 8.69KB 0.000u 0:00.000
hw180.jpg[3] JPEG 320x240 320x240+0+0 8-bit Gray 256c 5.61KB 0.000u 0:00.000
hw20.png[4] PNG 320x240 368x344-40139926+18 8-bit sRGB 26.4KB 0.000u 0:00.000
hw180.png[5] PNG 320x240 368x344-40139926+18 8-bit RGB 256c 20.2KB 0.000u 0:00.000
hw20.miff[6] MIFF 320x240 320x240+0+0 8-bit TrueColor sRGB 231KB 0.000u 0:00.000
hw180.miff[7] MIFF 320x240 320x240+0+0 8-bit Grayscale Gray 77KB 0.000u 0:00.000

The hw20.* images have visible green text and all 3 formats identify them as being sRGB.
The hw180.* images are all gray, and are identified by PNG as "RGB", by JPEG as "Gray",
and by PNM as "Grayscale Gray", and by MIFF as "Grayscale Gray".

[fmw42]

The hw180.* images are all gray, and are identified by PNG as "RGB", by JPEG as "Gray",

So do you consider that a bug, since we got away from linear gray quite a whlle ago.

[glennrp]

The bug seems to be in "identify". "identify file.png" says it's RGB while "identify -verbose file.png" says it's Gray.

[fmw42]

Thanks Glenn. That does seem odd.

[glennrp]

I had missed the "getting away from linear gray quite a while ago". It may have happened last summer while I was off line for a few weeks. I'll go ahead and fix the png decoder again.

[snibgo]

There is no "gAMA" chunk in the input file. ImageMagick is inserting "gamma = 1" because it detects that the image is grayscale.

If IM is doing this, that is bad behaviour, isn't it? When IM reads any image of unknown gamma, it should assume sRGB, which is gamma approx 1/2.2.

[glennrp]

Fixed in SVN revision 17086 which will be released as version 6.9.0-1.

[glennrp]

Thanks Glenn. That does seem odd.

It's because we can't reset the colorspace before the pixels have been read, and for non-verbose identify we return before reading the pixels. With my latest fix, "identify" will report sRGB while "identify -verbose" will report Gray.

[fmw42]

But what gamma will identify -verbose show?

Also what will be returned from

convert image.png -format "%[colorspace]" info:

and

convert image.png -format "%[type]" info:

and

convert image.png -format "%[gamma]" info:

They need to show as gray and 0.4545..., I would think/expect.

[fmw42]

I have verified that things are now fixed in IM 6.9.0.1 betato correct to non-linear gray, as glenn described


im6901beta identify hw_180_wristband_none.png
hw_180_wristband_none.png PNG 320x240 368x344-40139926+18 8-bit sRGB 256c 20.2KB 0.000u 0:00.000

im6901beta convert hw_180_wristband_none.png -format "%[colorspace]\n" info:
Gray

im6901beta convert hw_180_wristband_none.png -format "%[type]\n" info:
Grayscale

im6901beta convert hw_180_wristband_none.png -format "%[gamma]\n" info:
0.454545

im6901beta identify -verbose hw_180_wristband_none.png
Image: hw_180_wristband_none.png
Format: PNG (Portable Network Graphics)
Mime type: image/png
Class: PseudoClass
Geometry: 320x240+0+0
Resolution: 100x100
Print size: 3.2x2.4
Units: Undefined
Type: Grayscale
Base type: Grayscale
Endianess: Undefined
Colorspace: Gray
....
Gamma: 0.454545


Thanks Glenn