Last modified: 2012-04-16 09:15:55 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T30631, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 28631 - Animated GIF has black artifacts when scaled
Animated GIF has black artifacts when scaled
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
File management (Other open bugs)
unspecified
All All
: Normal normal (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-04-20 20:51 UTC by Logan Rosen
Modified: 2012-04-16 09:15 UTC (History)
5 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Logan Rosen 2011-04-20 20:51:05 UTC
See this photo:
http://commons.wikimedia.org/wiki/File:Bouncywikilogo.gif

It appears to be a newer issue with thumbnail generation, as, even when reverting back to the older versions where black artifacts do not appear on the thumbnails on the file description page, the black artifacts reappear when reverting to those seemingly good older versions.

I have tested this on Firefox 6.0a1 and Chrome 12.0.733.0, and both display black artifacts in the thumbnails.
Comment 1 Bawolff (Brian Wolff) 2011-04-20 20:57:27 UTC
Probably related to bug 27859 (Except that one appeared to stop happening, where this one is still current).

Probably some upstream issue with imageMagick...
Comment 2 Bryan Tong Minh 2011-04-22 18:29:17 UTC
Can reproduce with Windows ImageMagick 6.6.4-0 2010-09-04 Q16
Comment 3 Mark A. Hershberger 2011-04-26 03:15:10 UTC
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.
Comment 4 Mark A. Hershberger 2011-04-28 00:15:40 UTC
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.
Comment 5 Brion Vibber 2011-04-28 00:54:48 UTC
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'.
Comment 6 Mark A. Hershberger 2011-04-28 19:40:35 UTC
(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.
Comment 7 Mark A. Hershberger 2011-04-28 20:25:13 UTC
Took +map out in r87099.  Not setting this to FIXED because it needs more testing.
Comment 8 Mark A. Hershberger 2011-05-01 20:20:09 UTC
marking fixed for now.
Comment 9 Derk-Jan Hartman 2011-06-08 13:31:06 UTC
(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.
Comment 10 Tim Starling 2011-08-13 11:46:46 UTC
(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.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links