jeluf wrote:

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.

jeluf wrote:

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?

dbenbenn wrote:

(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.

hugo.lpz wrote:

See the test area : [http://commons.wikimedia.org/wiki/Gif_animation_Bug]

hugo.lpz wrote:

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.

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.

Attached:

jeluf wrote:

Fixed in rev 14433
Delpoyed.

jeluf wrote:

*** Bug 6183 has been marked as a duplicate of this bug. ***

hugo.lpz wrote:

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 ....

hugo.lpz wrote:

[[: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 = ();

}

jreid wrote:

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.