The PNG file seems ok:
Code: Select all
glenn.rp> pngcheck -v roseg_gamma2.png
File: roseg_gamma2.png (2887 bytes)
chunk IHDR at offset 0x0000c, length 13
70 x 46 image, 8-bit grayscale, non-interlaced
chunk gAMA at offset 0x00025, length 4: 0.90909
chunk bKGD at offset 0x00035, length 2
gray = 0x00ff
chunk IDAT at offset 0x00043, length 2702
zlib: deflated, 4K window, maximum compression
chunk tEXt at offset 0x00add, length 37, keyword: date:create
chunk tEXt at offset 0x00b0e, length 37, keyword: date:modify
chunk IEND at offset 0x00b3f, length 0
No errors detected in roseg_gamma2.png (7 chunks, 10.3% compression).
and the gamma=0.90909 makes sense:
Code: Select all
glenn.rp> dc
8 k
2 2.2 / p
.90909090
q
glenn.rp>
So the colorspace seems to be getting added while reading it
back in, in the second command. This extract from the log:
Code: Select all
Enter ReadPNGImage()
Enter ReadOnePNGImage()
IM version = 6.8.8-7
Libpng version = 1.7.0beta33
Zlib version = 1.2.8
Before reading:
image->matte=0
image->rendering_intent=2
image->colorspace=13
image->gamma=0.454545
Found PNG gAMA chunk.
Reading PNG gAMA chunk: gamma: 0.909090
shows that the image has already been labeled as sRGB before
it begins reading the PNG datastream, but then the gamma
gets reset when the gAMA chunk is decoded.
The bug here is that later, coders/png.c checks for image->gamma==1.0 to
decide whether to reset the colorspace. I guess something
like image->gamma > 0.75 would work more like people expect.
I'll make that change.