Page 1 of 1

[RESOLVED]Possible bug PNG:32 write losing colors IM 6.7.9.0

Posted: 2012-08-20T15:44:39-07:00
by fmw42
IM 6.7.9.0 Q16 Mac OSX Snow Leopard.

Writing to PNG32 seems to convert 256 shades of gray to 183.

Input (sRGB grayscale):
http://www.fmwconcepts.com/misc_tests/t ... -gray.jpeg

convert sample-gray.jpeg -format "%k" info:
256


The following keeps all 256 shades of gray:

convert sample-gray.jpeg \
\( -clone 0 -fill black -colorize 100% \) \
\( -clone 0 -negate \) \
-delete 0 -alpha off -compose copy_opacity -composite -format "%k" info:
256



But when saved to PNG32: it becomes only 183 shades of gray

convert sample-gray.jpeg \
\( -clone 0 -fill black -colorize 100% \) \
\( -clone 0 -negate \) \
-delete 0 -alpha off -compose copy_opacity -composite PNG32:- | convert - -format "%k" info:
183

Re: Possible bug PNG:32 write losing colors IM 6.7.9.0 Q16

Posted: 2012-08-20T19:38:29-07:00
by glennrp
I get the same result if I use MIFF:- or TXT:- so it does not appear to be a PNG encoding problem.

Re: Possible bug PNG:32 write losing colors IM 6.7.9.0 Q16

Posted: 2012-08-20T19:41:45-07:00
by fmw42
glennrp wrote:I get the same result if I use MIFF:- or TXT:- so it does not appear to be a PNG encoding problem.
You are right. It happens for MIFF also. But it is strange that it does not happen until some format is specified as this works fine:

convert sample-gray.jpeg \
\( -clone 0 -fill black -colorize 100% \) \
\( -clone 0 -negate \) \
-delete 0 -alpha off -compose copy_opacity -composite -format "%k" info:
256


P.S. Glenn added this in PM to me.
glennrp wrote:The problem does not seem to be in the PNG encoder because TXT:- and MIFF:- produce the same "183". Oddly, some other formats behave differently. PPM:- and PNM:- give "1", and PNG8- and GIF:- produce "2". ../glennrp

Re: Possible bug PNG:32 write losing colors IM 6.7.9.0 Q16

Posted: 2012-08-20T19:51:38-07:00
by fmw42
Oddly, this works with PNG and MIFF by adding -set colorspace RGB:

convert sample-gray.jpeg \
\( -clone 0 -fill black -colorize 100% \) \
\( -clone 0 -negate \) \
-delete 0 -alpha off -set colorspace RGB -compose copy_opacity -composite PNG32:- | convert - -format "%k" info:
256



But this does not:

convert sample-gray.jpeg \
> \( -clone 0 -fill black -colorize 100% \) \
> \( -clone 0 -negate \) \
> -delete 0 -alpha off -set colorspace RGB -compose copy_opacity -composite GIF:- | convert - -format "%k" info:
2

convert sample-gray.jpeg \
> \( -clone 0 -fill black -colorize 100% \) \
> \( -clone 0 -negate \) \
> -delete 0 -alpha off -set colorspace RGB -compose copy_opacity -composite PNM:- | convert - -format "%k" info:
1

Re: Possible bug PNG:32 write losing colors IM 6.7.9.0 Q16

Posted: 2012-08-22T11:16:45-07:00
by magick
Your input image is sRGB:
  • convert sample-gray.jpeg -colorspace gray sample-gray.miff
    identify -verbose sample-gray.jpeg
returns 183 colors after decompanding. One solution would be to save the sample-gray in the grayscale JPEG colorspace, a linear colorspace. ImageMagick asks the JPEG decoder for the colorspace when it reads the image, its currently returning sRGB instead of grayscale. The other solution is the -set colorspace GRAY. That tells ImageMagick the colorspace is linear and therefore there is no need to remove the gamma function.

Re: Possible bug PNG:32 write losing colors IM 6.7.9.0 Q16

Posted: 2012-08-22T12:15:05-07:00
by fmw42
magick wrote:Your input image is sRGB:
  • convert sample-gray.jpeg -colorspace gray sample-gray.miff
    identify -verbose sample-gray.jpeg
returns 183 colors after decompanding. One solution would be to save the sample-gray in the grayscale JPEG colorspace, a linear colorspace. ImageMagick asks the JPEG decoder for the colorspace when it reads the image, its currently returning sRGB instead of grayscale. The other solution is the -set colorspace GRAY. That tells ImageMagick the colorspace is linear and therefore there is no need to remove the gamma function.
I/we want to keep the 256 colors that are in the input image when making the alpha channel, so that the alpha channel has 256 grays.

Your suggestion works for PNG and MIFF and PAM. I was on the wrong track testing with GIF as it supports only binary alpha and PNM/PBM does not support alpha, only PAM.

These work:

convert sample-gray.jpeg -set colorspace gray \
\( -clone 0 -fill black -colorize 100% \) \
\( -clone 0 -negate \) \
-delete 0 -alpha off -compose copy_opacity -composite PNG32:- | convert - -format "%k" info:
256

convert sample-gray.jpeg -set colorspace gray \
\( -clone 0 -fill black -colorize 100% \) \
\( -clone 0 -negate \) \
-delete 0 -alpha off -compose copy_opacity -composite MIFF:- | convert - -format "%k" info:
256

convert sample-gray.jpeg -set colorspace gray \
\( -clone 0 -fill black -colorize 100% \) \
\( -clone 0 -negate \) \
-delete 0 -alpha off -compose copy_opacity -composite PAM:- | convert - -format "%k" info:
256

Thanks for the help


So this should be what is wanted:


convert sample-gray.jpeg -set colorspace gray \
\( -clone 0 -fill black -colorize 100% \) \
\( -clone 0 -negate \) \
-delete 0 -alpha off -compose copy_opacity -composite PNG32:sample_gray_correct.png

Image