possible bug %[colorspace] IM 6.8.8.7 Q16 Mac OSX

Post any defects you find in the released or beta versions of the ImageMagick software here. Include the ImageMagick version, OS, and any command-line required to reproduce the problem. Got a patch for a bug? Post it here.
Post Reply
User avatar
fmw42
Posts: 25562
Joined: 2007-07-02T17:14:51-07:00
Authentication code: 1152
Location: Sunnyvale, California, USA

possible bug %[colorspace] IM 6.8.8.7 Q16 Mac OSX

Post by fmw42 »

The string format %[colorspace] is not producing correct results for grayscale images.

Code: Select all

convert rose: -colorspace gray roseg.png

convert roseg.png -format "%[colorspace]" info:
sRGB   <---- should be Gray
and similarly

Code: Select all

convert rose: -colorspace gray -gamma 2 roseg_gamma2.png

convert roseg_gamma2.png -format "%[colorspace]" info:
RGB   <---- should be Gray

Note it was producing correct results (Gray) at IM 6.8.6.0 and changed somewhere after that but before IM 6.8.9.0
User avatar
glennrp
Posts: 1147
Joined: 2006-04-01T08:16:32-07:00
Location: Maryland 39.26.30N 76.16.01W

Re: possible bug %[colorspace] IM 6.8.8.7 Q16 Mac OSX

Post by glennrp »

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.
snibgo
Posts: 12159
Joined: 2010-01-23T23:01:33-07:00
Authentication code: 1151
Location: England, UK

Re: possible bug %[colorspace] IM 6.8.8.7 Q16 Mac OSX

Post by snibgo »

As a minor aside, I'll comment that when I use "-gamma X" but I want the image to be treated as sRGB, I always follow this with "-set gamma 0.454545". Otherwise, image viewers that regard gamma settings don't do what I want.
snibgo's IM pages: im.snibgo.com
User avatar
fmw42
Posts: 25562
Joined: 2007-07-02T17:14:51-07:00
Authentication code: 1152
Location: Sunnyvale, California, USA

Re: possible bug %[colorspace] IM 6.8.8.7 Q16 Mac OSX

Post by fmw42 »

Yes, it would appear to be limited to PNG.

Code: Select all

convert rose: -colorspace gray roseg.jpg
convert roseg.jpg -format "%[colorspace]" info:
Gray

Code: Select all

convert rose: -colorspace gray roseg.tif
convert roseg.tif -format "%[colorspace]" info:
Gray
Just for reference, I point out that it was producing correct results (Gray) for PNG at IM 6.8.6.0 and changed somewhere after that but before IM 6.8.9.0
Post Reply