Legacy ImageMagick Discussions Archive

I've been using imagemagick to split super-wide video analysis graph images generated by Shotdetect without problems for years now (ImageMagick v6.6.0-4 2012-05-03 Q16, Debian 6).

With the version in Debian 7's repositories (ImageMagick v6.7.7-10 2014-03-08 Q16) I now get the following error:

convert.im6: invalid colormap index `motion_qty.png' @ error/image.c/SyncImage/4270.

It produces the cropped images, but removes pixels with a certain color from the output.

The command used is:

Code: Select all

$ convert motion_qty.png -crop 30000 motion_qty-%02d.png

I can reproduce the error with the current Windows binary (v6.9.0-6 Q16 x64 2015-02-07), so I assume it's still an issue in recent ImageMagick builds.

I've uploaded a sample PNG that causes this error.
"identify" says it's:

PNG 3018x400 3018x400+0+0 8-bit PseudoClass 7c 5.71KB 0.000u 0:00.010

Any help appreciated.
Thank you very much in advance!

If your image is only 3018x400, then why use a crop size that is 10x larger. I do not understand what you are trying to do. See the proper use of -crop including +repage at http://www.imagemagick.org/Usage/crop/#crop and the following sections. The repage is needed to remove an remaining virtual canvas, which could cause you problems. What do you mean by removing colors? Perhaps you need to upgrade your libpng?

Perhaps you could explain what you are trying to do with your crop?

I'll have a look. pngcheck says:

glenn.rp> pngcheck -v i*
File: imagemagick-invalid_colormap_index.png (5715 bytes)
chunk IHDR at offset 0x0000c, length 13
3018 x 400 image, 4-bit palette, non-interlaced
chunk PLTE at offset 0x00025, length 21: 7 palette entries
chunk IDAT at offset 0x00046, length 5625
zlib: deflated, 32K window, default compression
chunk IEND at offset 0x0164b, length 0
No errors detected in imagemagick-invalid_colormap_index.png (4 chunks, 99.1% compression).

so it looks as though we may have a bug with how 4-bit samples are handled. As Fred said, it might
be a problem in libpng. What do you get from

Code: Select all

convert -list format | grep PNG24

I note that with this file, pngcrush 1.7.74 says:

Code: Select all

libpng warning: IDAT: Read palette index exceeding num_palette
While converting bad_colormap_index.png to b1.png:

The -crop 30000 doesn't make sense but it has nothing to do with the bug. Simply running

Code: Select all

convert  imagemagick-invalid_colormap_index.png output.png

also fails with the bad colormap index error. convert is trying to write a 2-bit output image because the file only contains 3 colors: black, white, and red. Adding -depth 4 or -depth 8 doesn't make any difference.

Thanks for all your input!

If the PNG is invalid (which I do not doubt), why did it work with previous versions of ImageMagick? (e.g. I've just tried with v6.6.9-7 (Q16 2014-03-06)

I've checked the sourcecode of shotdetect, and it uses libgd to generate the PNGs. I've also checked the paletted color assignments in the code, and I wouldn't know what to fix (or where it went wrong). All 7 colors used in the graph are properly allocated using "gdImageColorAllocate()".
Additionally, all other programs I tried that PNG graph with, open it without problems.

Would it be possible to make ImageMagick be able to handle that flavor of paletted PNG?

Thanks again

Perhaps you older version of IM was using a more forgiving version of libpng

The error message is coming from IM not libpng.
To find out which version of libpng your IM is using, type

Code: Select all

convert -list format | grep PNG

The output of "convert -list format | grep PNG" is as follows:

Code: Select all

      JNG* PNG       rw-   JPEG Network Graphics
      MNG* PNG       rw+   Multiple-image Network Graphics (libpng 1.2.49)
      PNG* PNG       rw-   Portable Network Graphics (libpng 1.2.49)
           See http://www.libpng.org/ for details about the PNG format.
    PNG24* PNG       rw-   opaque 24-bit RGB (zlib 1.2.7)
    PNG32* PNG       rw-   opaque or transparent 32-bit RGBA
     PNG8* PNG       rw-   8-bit indexed with optional binary transparency

So it looks like "libpng v1.2.49". That would correlate with the version of Debian 7's "libpng3" package.
Is there any way I could test if it's an issue in ImageMagick or libPNG?

Thanks

^rooker wrote:.
Is there any way I could test if it's an issue in ImageMagick or libPNG?

The issue is with neither. It is with the application that is creating the invalid PNG files. Older versions of IM or libpng
might have allowed them, by writing beyond the colormap memory allocation. We don't want to do that any more, for security reasons.

The current libpng version in the libpng12 (libpng.so.3) series is libpng-1.2.52. I don't know what version of libpng came with Debian 6.

Hm...
I'll check if I can find how to modify shotdetect's code to produce "spec conform PNGs", but from what I saw so far, it seems to be something inside libgd that's not allocating the colormap correctly. Will contact them, then.
I'm still wondering why all other applications seem to handle those PNGs fine, though.

Thanks for your help!

Legacy ImageMagick Discussions Archive

"invalid colormap index" with index PNG

"invalid colormap index" with index PNG

Re: "invalid colormap index" with index PNG

Re: "invalid colormap index" with index PNG

Re: "invalid colormap index" with index PNG

Re: "invalid colormap index" with index PNG

Re: "invalid colormap index" with index PNG

Re: "invalid colormap index" with index PNG

Re: "invalid colormap index" with index PNG

Re: "invalid colormap index" with index PNG

Re: "invalid colormap index" with index PNG

Re: "invalid colormap index" with index PNG