Legacy ImageMagick Discussions Archive

Still the same problem with latest release: linux # convert -version Version: ImageMagick 6.8.7-2 2013-10-24 Q8 http://www.imagemagick.org Copyright: Copyright (C) 1999-2013 ImageMagick Studio LLC Features: DPC OpenMP Delegates: bzlib fontconfig freetype jbig jng jp2 jpeg lcms ltdl lzma png png tiff ...

Bump? No new releases of IM in the last month?

6.8.7 has the same issue under linux: linux # convert -version Version: ImageMagick 6.8.7-0 2013-10-07 Q8 http://www.imagemagick.org Copyright: Copyright (C) 1999-2013 ImageMagick Studio LLC Features: DPC OpenMP Delegates: bzlib fontconfig freetype jbig jng jp2 jpeg lcms ltdl lzma png png tiff xml ...

Okay, it appears that 6.8.6-10 works well for Mac, but does not work properly on Linux: linux # convert -version Version: ImageMagick 6.8.6-10 2013-09-24 Q8 http://www.imagemagick.org Copyright: Copyright (C) 1999-2013 ImageMagick Studio LLC Features: DPC OpenMP Delegates: bzlib fontconfig freetype ...

Looks like it has been fixed by something else in some later version: mac % % convert -version 1 ↵ Version: ImageMagick 6.8.6-10 2013-09-23 Q16 http://www.imagemagick.org Copyright: Copyright (C) 1999-2013 ImageMagick Studio LLC Features: DPC Delegates: bzlib freetype jng jpeg ltdl png png xml zlib m ...

# convert rgb-no-alpha.png -format "%[fx:minima.a] %[fx:maxima.a]" info: 1.33333e+36 -1.33333e+36 These values make no sense for either Q16 or Q8. Looks like your system may be corrupted or has some bad bugs in that version. I get this same result on both Mac and Linux. There is very little chance ...

On Mac OS X 10.8.5:
On Debian Linux (Wheezy):

It seems that using the "o" channel (whatever that is) seems to work better: # convert rgb-alpha-partial.png -channel o -separate +channel -format "%[fx:minima] %[fx:maxima]" info: 0.501961 1 This is the correct result for this partially transparent image. But it doesn't work properly for an image ...

# convert rgb-no-alpha.png -channel a -separate -format "%[min]" info: 3.4e+38 # convert rgb-no-alpha.png -format "%[fx:minima.a]" info: 1.33333e+36 # convert rgb-no-alpha.png -format "%[fx:minima.a] %[fx:maxima.a]" info: 1.33333e+36 -1.33333e+36 And here's output for an image with an alpha channel ...

On my Mac OSX IM 6.8.6.10 Q16 it works fine. But try adding +channel after the -separate and see if that makes a difference It's ImageMagick on Linux that displays the bug, not OSX, but your suggestion did not work: # convert rgb-no-alpha.png -channel a -separate +channel -format "%[fx:minima ...

D:\web\im>"%IMG68610%convert" rgb_no_alpha.png -channel a -separate -format "%[fx:minima]" info: 0.999893 On Mac with IM v6.8.6-3 I get a result of "1", not your less-than-1 float: % convert rgb-no-alpha.png -channel a -separate -format "%[fx:minima]" info: 1 But on Linux (Debian) with v6.8.6-9 I ...

Actually that doesn't seem to be correct either, because minima still returns 0 for an image with no alpha channel: // this should output: 1 1 // but instead it outputs: 0 1 convert rgb-no-alpha.png -channel a -separate -format '%[fx:minima] %[fx:maxima]' info: // this should output: 0 1 convert rgb ...

As it turns out, there is an easy work around. The value of can be compared to maxima. If the value of maxima is not 1, or the values are not equal, the image must have variation in the alpha channel.

I believe this has resulted in a regression. It used to be that this command would return "0" for any image without an alpha channel, but now results in "1" for images without an alpha channel: // expected to return a value between 0.1 and 1 convert rgb-alpha.png -channel a -separate -format "%[fx ...