Legacy ImageMagick Discussions Archive

Hello,

When running a composite command in ImageMagick 6.7.8 I get the following error:
composite: invalid colormap index `text.png' @ error/image.c/SyncImage/3464.

This is the command:
composite -gravity center gradient.png text.png label.png

Here are the 2 input files:
https://dl.dropbox.com/u/219844/colormap.zip

Is this a bug?

Regards, Marcel

It is a bug in the application that created text.png.
It has a 174-entry color palette, but the indices are
all 0 or 255. 255 is out of range.

The image is white letters PBM on a rose-colored background.
text.png also contains date:create: and date:modify:

• date:create: 2012-08-15T00:57:42+02:00
  date:modify: 2012-08-15T00:57:42+02:00
  label: PBM

properties, so there's a good chance that it was ImageMagick
that created text.png. Can you show the command you used
to create it?

convert -depth 8 -background '#ff60b0' -font Helvetica -pointsize 92 -strokewidth 1 -stroke white -fill white -size 330x120 -gravity south label:'PBM' text.png

I can't reproduce your text.png with ImageMagick-6.7.8-10 or with other recent releases back to 6.6.6-1. I get a valid two-entry palette.

I'm running ImageMagick 6.7.8-3 2012-08-07 Q16 installed with MacPorts 2.1.1 on OS X 10.8
Does that help?

I suppose it helps. I am getting different results on different platforms, which must be caused by different versions of the supporting libraries.
On my own Ubuntu 10.04 platform I get a two-entry palette, but on studio.imagemagick.org I get a valid 170-element PLTE and on magick.imagemagick.org I get a valid 174-element PLTE.

I don't know if this is relevant, but according to "convert -list format"
studio used FreeType 2.2.1
magick used FreeType 2.4.8
glennrp used an unnamed Truetype font collection

None of these platforms exhibit the invalid palette entry problem.

I suppose it helps -- sorry for the double post.

I'm at 2.4.10 with FreeType.

I rebuilt IM-6.7.8-10 on my own Ubuntu platform and now it produces
the same PLTE as yours, with 174 valid entries. The file is twice the size
of your text.png, though, due to a larger IDAT chunk.

I guess the next question is what libpng/libz did you use?
convert -list format | grep PNG
gives me
PNG* rw- Portable Network Graphics (libpng 1.5.12)
PNG24* rw- opaque 24-bit RGB (zlib 1.2.5)

Glenn

PNG* PNG rw- Portable Network Graphics (libpng 1.4.12)
PNG24* PNG rw- opaque 24-bit RGB (zlib 1.2.7)

These are the latest provided by MacPorts.

Thanks for the time you put into it.

I am able to reproduce the problem with IM-6.7.8-3. It appears to be due
to a bug in coders/png.c that was fixed in IM-6.7.8-5.

That's good news. Thank you, Glenn.