Last modified: 2007-04-27 18:03:15 UTC
See the URL testcase.
This is a ImageMagick issue. To reduce filesize, for every frame only the part of the image that has changed is saved, together with a vector pointing to the origin of that area. Apparently, this vector gets lost. I'm just compiling ImageMagick 6.6.1 to verify whether this issue still exists.
There's a hint at http://studio.imagemagick.org/magick/viewtopic.php?t=2211&highlight=animated To resize an animated GIF, one needs to use '-scale xx%' instead of '-geometry "width"x"height"' Have to check how this can be implemented in MediaWiki.
What's the status of this? The problem seems to persist, see <http://upload.wikimedia.org/wikipedia/commons/thumb/1/12/%E9%97%AE-order.gif/70px-%E9%97%AE-order.gif> for example, a scaled version of <http://commons.wikimedia.org/wiki/Image:%E9%97%AE-order.gif>. Is this a bug in ImageMagick, or can it be resolved by tweaking it a bit?
(In reply to comment #3) > What's the status of this? The problem seems to persist > Is this a bug in ImageMagick, or can it be resolved by tweaking it a bit? Well, it's definitely a bug in ImageMagick. But JeLuF's suggestion seems like a good workaround (it worked on the test I tried). So this bug could be mostly fixed by tweaking MediaWiki a bit.
See the test area : [http://commons.wikimedia.org/wiki/Gif_animation_Bug]
Please, may we know when that should be fixe ? (in the week / month / 3 month ?). Thanks~~
Well, its really a bug in ImageMagick, not in MediaWiki, so you should ask them about it. It may be possible to work around it as JeLuF suggested, but when I asked brion about it, he said that proportinal scaling is likely to introduce other problems. Fundamentally, it's an upstream issue that needs to be fixed in ImageMagick. That being said: i'd like to have a workaround too, even if it means that the size of the scaled gifs may be off by a pixel or two.
Created attachment 1781 [details] Add "-coalesce" to the ImageMagick convert options This patch, which simply adds the "-coalesce" option to the ImageMagick command line, should fix the problem. The rescaled animations will not be optimized -- but they never were, anyway, so no regression here.
Fixed in rev 14433 Delpoyed.
*** Bug 6183 has been marked as a duplicate of this bug. ***
Thanks, thanks, thanks, thanks ! from the little team working on the commons Chinese stroke order project, see http://commons.wikimedia.org/wiki/Category:Chinese_stroke_order_in_animated_GIF and [[Category:Chinese stroke order]] All the "team" is thanking you :] Yug , Wikic, Muke, M4RC0, Ignis ....
[[:commons:Category:Chinese stroke order]]
It seems old thumbnails created before the patch was deployed are still broken. Purging all (animated) GIF thumbs created before 2006-05-29 or so should do it -- simple enough, but needs someone with shell access to do it. Changing keywords accordingly.
To find the thumbs that need deleting, the following commands should work: $ touch -d 2005-05-29 /tmp/timestamp-2005-05-29 $ find THUMBDIR -exec sleep 1 \; -iname \*.gif -not -newer /tmp/timestamp-2005-05-29 -print >filelist1.txt $ perl -lne 'sleep 10; print if grep / GIF / && !/ GIF (\d+x\d+) \1\+0\+0 /, `identify '\''$_'\'' 2>&1`' filelist1.txt >filelist2.txt where THUMBDIR is the directory (or directories) containing the thumbnails. All those sleep commands are there to slow it down so it doesn't hit the servers too hard. After reviewing the list, the deletion itself can be done slowly and verbosely with: $ perl -lne 'print STDERR "Deleting $_ ... "; sleep 1; if (unlink $_) { warn "OK\n" } else { warn "Error: $!\n" }' filelist2.txt
Here's an improved command to produce the list of files to delete: perl -MTime::HiRes=sleep -MFile::Find -e 'find sub {sleep 0.01; print "$File::Find::name\0" if /\.(jpe?g|gif)$/i and -f}, @ARGV' THUMBDIR | xargs -0 -n 100 identify 2>/dev/null | perl -lne '/^(.*?)(?:\[\d+\])? (JPEG|GIF) (\d+)x(\d+) (\3x\4\+0\+0)?/ or next; print $1 if $2 eq "JPEG" and -s $1 > 0.5*$3*$4 or $2 eq "GIF" and not $5;' | uniq >filelist.txt This one does 100 thumbs per second, which should be fast enough to complete in reasonable time but slow enough not to kill the servers. It uses perl and xargs to avoid spawning needlessly many processes, and also triggers on unusually large JPEG thumbs (see r16811). This is really more of a note for myself, to remind me that I should get someone with shell access to run this.
Same code as a single perl script with proper indentation and no modules: #!/usr/bin/perl -w use strict; my $t0 = time; my $n = 0; my @queue; while (@ARGV) { my $delay = int($n++/100) - (time - $t0); sleep $delay if $delay > 0; my $name = pop @ARGV; if (-d $name) { opendir D, $name or die "opendir($name): $!\n"; while (my $entry = readdir D) { push @ARGV, "$name/$entry" if $entry !~ /^\.\.?\z/; } closedir D or die "closedir($name): $!\n"; } elsif (-f _) { push @queue, $name if $name =~ /\.(jpe?g|gif)\z/i; } next if @ARGV and @queue < 100; open P, "-|", "identify", @queue or die "pipe open: $!\n"; while (<P>) { /^(.*?)(\[\d+\])? (JPEG|GIF) (\d+)x(\d+) (\3x\4\+0\+0)?/ or next; print "$1\n" if ($3 eq "GIF" and not $6 or $3 eq "JPEG" and -s $1 > 0.5*$4*$5); } close P or die "pipe close: $!\n"; @queue = (); }
The bug -- or a closely related one -- may remain. See: http://en.wikipedia.org/wiki/Image_talk%3APi-unrolled-opt1.gif#No_good The non-optimized version scales fine; this doesn't. Note that this particular optimization does *not* crop frames to only the changed boundsrect. On consideration, I'm starting to wonder if there is any point in fixing this further. No amtter how clever or careful the optimization of the upload, the delivered thumb is not optimized anyway. If the upload is intended to be viewed at full size, then it can be optimized and this bug doesn't come into play; if it is intended to be resized, it can be uploaded in vanilla state. The only issue is in certain gallery situations -- not just those using the tag -- where a basket of images are going to be treated alike, perhaps with little consideration from the editor who assembles it. The extreme case is of the Category gallery; optimized animated GIFs are just not going to display properly there. I'm going to downgrade this bug.
This seems reasonably resolved at this time, and purge should more or less work these days.