Probably related to bug 27859 (Except that one appeared to stop happening, where this one is still current).

Probably some upstream issue with imageMagick...

Bryan.TongMinh wrote:

Can reproduce with Windows ImageMagick 6.6.4-0 2010-09-04 Q16

Command line to reproduce with the above image:

convert -quality 95 -background white Bouncywikilogo.gif -coalesce -thumbnail 120x120 -depth 8 -auto-orient -fuzz 5% -layers optimizeTransparency +map thumb.gif

Removing "+map" gets rid of the artifacts, though.

Note that removing the "+map" option not only gets rid of the
artifacts, it also reduces the final size (in this case) from 143253
to 137632 bytes.

I can confirm here with ImageMagick 6.6.2-6 (Ubuntu 10.10 x86_64).

The '+map' (along with the -fuzz and layer optimization) was added in r71354 for bug 11822:

"I also tried adding +map to reduce to prevent per
frame colortables, but this option doesn't deal very well with transparency
unfortunately (because it does significantly reduce filesize)."

My current man pages don't list the '+map' option for convert, but older ones floating on the internet do:

-map filename

choose a particular set of colors from this image.

By default, color reduction chooses an optimal set of colors that best represent the original image. Alternatively, you can choose a particular set of colors from an image file with this option. Use +map to reduce all images provided on the command line to a single optimal set of colors that best represent all the images.

The '+map' tells it to rebuild the colormap from the input files, so presumably this is behaving differently from the default (given that it's the same input file, still). Somehow in the process of converting colors we lose some of the transparency, and various chunks of various frames are getting mapped to a non-transparent color by mistake.

In theory an animated GIF can have different color maps for each frame, but I don't know if that's a case that's actually hitting stuff.

I'm a bit unclear on if/where there's a bug tracker for ImageMagick, but there are forums where you can report bugs in the 'bugs' section. I don't see any entries searching for 'map animated gif'.

(In reply to comment #5)

I'm a bit unclear on if/where there's a bug tracker for ImageMagick, but there
are forums where you can report bugs in the 'bugs' section.

Yeah, I couldn't find one either. Gonna send someone an email, I guess.

But I think it would be worthwhile to take out the "+map" parameter for animations since it is (evidently) doing more harm than good.

Took +map out in r87099. Not setting this to FIXED because it needs more testing.

marking fixed for now.

(In reply to comment #5)

In theory an animated GIF can have different color maps for each frame, but I
don't know if that's a case that's actually hitting stuff.

Not theory, I believe this is why I added the option in the first place. Should be somewhere in our bugzilla history.

(In reply to comment #5)

I'm a bit unclear on if/where there's a bug tracker for ImageMagick, but there
are forums where you can report bugs in the 'bugs' section. I don't see any
entries searching for 'map animated gif'.

They use phpBB. Follow the "discourse server" link at the bottom of the ImageMagick home page.

http://www.imagemagick.org/discourse-server/viewforum.php?f=3

John Cristy (a.k.a. magick) is extremely responsive to new posts there, he often commits a fix within a day. But you should try to isolate the bug a bit better than what I see above if you want to report it upstream. It's not clear to me from the comments above whether there is any ImageMagick bug. Nobody here seems to know what +map is meant to do, so maybe it's working as intended.