Incorrect gAMA in PNGs written by ImageMagick

[psychon]

Hi,

let's try some commands:

Code: Select all

$ wget 'http://git.naquadah.org/?p=awesome.git;a=blob_plain;f=themes/default/titlebar/close_focus.png;hb=HEAD' -O orig.png
[...]
$ identify orig.png > /dev/null
$ convert orig.png -gamma 0.6 -channel A -evaluate Multiply 0.4 res.png
$ identify res.png > /dev/null 
incorrect gamma=(0/100000)
identify.im6: Ignoring incorrect gAMA value when sRGB is also present `res.png' @ warning/png.c/MagickPNGWarningHandler/1754.
$ convert res.png res2.png
incorrect gamma=(0/100000)
convert.im6: Ignoring incorrect gAMA value when sRGB is also present `res.png' @ warning/png.c/MagickPNGWarningHandler/1754.
$ identify res2.png > /dev/null

What are we looking at? We get a random PNG file from the internet and check it with "identify". No error messages here.

Then "convert" gets used to get a translucent version of this image. This is a command that is used in some build system and should work with as many ImageMagick versions as possible. However, whenever the resulting image is loaded by any program, libpng prints a warning message.

But just sending the image through "convert" again, without changing anything, gets rid of that error.

Could this be a bug somewhere in ImageMagick? The output of "identify -verbose" doesn't get changed by that last "convert" call and I have no clue what exactly causes this error.

Alternatively, I would also happily learn about more sane ways to do this transformation with ImageMagick that works with older versions and ignore this issue, but it might still be something that should be fixed.

Thanks for looking into this.

[glennrp]

Because of the recent swap of sRGB and RGB colorspaces, the png decoder is inserting the sRGB chunk in color images. Your *orig file already has a gamma chunk with gamma=0.45,
so that seems to be a mistake. The effect of your "-gamma .6" directive is to multiply the .45 by the .6 resulting in gamma=0.27 being stored in the result. I don't know why
your "incorrect gamma" is 0; IM-6.8.0-2 is reporting 0.27.

Do the res.png and res2.png look the way you wanted? They are lighter than the original due to the changed value of gamma.

If you add "-colorspace rgb" to each "convert" command, the warnings go away, but the results are still pale:

Code: Select all

identify orig.PNG > /dev/null
convert -colorspace rgb orig.PNG -gamma 0.6 -channel A -evaluate Multiply 0.4 res.png
identify res.png > /dev/null 
convert -colorspace rgb res.png res2.png
identify res2.png > /dev/null

Note that if you simply "convert orig.PNG res3.png", res3.png gets the sRGB chunk, a cHRM chunk, and a new gAMA chunk with gamma=0.45455. Just doing "convert -colorspace RGB orig.PNG res4.png" doesn't add sRGB or cHRM chunks, but gamma is changed from .45 to .45455 since it is within a defined epsilon from 1/2.2.

[psychon]

Thanks for that info. I think that "-colorspace rgb" is fine with me. This call is used to automatically generate "unfocused" versions for a set of icons. These icons aren't displayed in any kind of color-calibrated way, so the gamma value shouldn't matter much for my use case.

I am using IM-6.7.7-10 btw (debian testing, amd64). Perhaps the problem that I am seeing was fixed with version 6.8?

[glennrp]

I am using IM-6.7.7-10 btw (debian testing, amd64). Perhaps the problem that I am seeing was fixed with version 6.8?

It's partly fixed. You still get the "incorrect gamma" message but at least it's reported (correctly) to be 0.27 instead of 0. But I think the sRGB data should be ignored instead of the gamma value, and that is what happens when you set colorspace to RGB.

[edit: This is fixed in SVN revision 9794, IM-6.8.0-4; the sRGB chunk is not written if image->gamma is not between 0.45 and 0.46].