Legacy ImageMagick Discussions Archive

Hello Magick Peoples

I ran the following under MacOSX 10.11.4 using ImageMagick 6.9.1-0 from the cactuslab binary.

I have run into a nasty bug that seems to be related to the number of colors in an image with an alpha channel. Like so.

convert CatHead_150x150.png -colors 65536 CatHead_150x150_65K.png

The input image URL: http://www.modejong.com/misc/CatHead_150x150.png

Even though the colortable size is very large, ImageMagick cannot seem to deal with the large number of color in the original image. The output is badly distorted. I tried this conversion with an alpha channel image on other less complex images (fewer total number of colors) and that worked fine, so it is likely that this bug is caused by some type of overflow or range issue related to the original number of colors.

I also tried to compose the alpha channel image over a white background before doing the compression, and that produce a great looking image. So, this seems to be a specific bug related to the alpha channel.

Max value for 16-bits is 65535 (0-65535). Don't know if you can use 65536 for a number (of colors) in a Q16 IM compile. What Q value is your IM compile -- what do you get from

> convert -version
Version: ImageMagick 6.9.1-0 Q16 x86_64 2015-03-22

I also see the bug with:

convert CatHead_150x150.png -colors 65535 CatHead_150x150_65K.png

A much smaller colortable also demonstrates the bug:

convert CatHead_150x150.png -colors 1024 CatHead_150x150_1024.png

What exactly is the bug? Can you post input and output images and explain what is wrong? You can upload to some place such as dropbox.com and put the URLs here.

The bug is serious corruption of the output file, you can see the exact results by downloading the image from http://www.modejong.com/misc/CatHead_150x150.png and then running:

convert CatHead_150x150.png -colors 65535 CatHead_150x150_65K.png

Running your command and image produces a result that looks fine to me on IM 6.9.5-3 Q16 Mac OSX Snow Leopard.

Try upgrading your IM version and perhaps libpng delegate.

Well, for starters, you only have 13293 different RGBA pixels present,
so "-colors 65535" should have no effect, if things are working properly:

• glenn.rp> convert CatHead_150x150.png cathead.txt
  glenn.rp> sort -u cathead.txt | wc
  13294 39880 645121

It has always bothered me that "-colors N" doesn't check that the image
already has N or fewer colors before doing the palette-generation.

So, I just tried it with imagemagick.org/MagickStudio and there did not seem to be a problem there, I used a table size of 1024 with preserve transparency and that did not corrupt the output image. ( ImageMagick Studio, version 7.02.)

I will try to download the source and build a static set of executables and see if that works. (I was not able to find a working binary for Mac OS X.)

see http://www.imagemagick.org/script/binar ... php#macosx

also here is what I do:

viewtopic.php?f=1&t=21502&p=88202&hilit ... rts#p88202

I was not able to use a precompiled Mac OS X binary, but I did get it to compile as a static library and now it seems to be working correctly. I compiled version 7.0.2-6 Q16 and the bug seems to be fixed now. Thanks much.