Last modified: 2007-04-27 18:03:15 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 T3017, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 1017 - Resize sometimes fails for animated GIFs in <gallery>
Resize sometimes fails for animated GIFs in <gallery>
Product: MediaWiki
Classification: Unclassified
File management (Other open bugs)
All All
: Normal minor with 2 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
: shell
: 6183 (view as bug list)
Depends on:
  Show dependency treegraph
Reported: 2004-12-06 12:16 UTC by Ævar Arnfjörð Bjarmason
Modified: 2007-04-27 18:03 UTC (History)
2 users (show)

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

Add "-coalesce" to the ImageMagick convert options (598 bytes, patch)
2006-05-18 17:08 UTC, Ilmari Karonen

Description Ævar Arnfjörð Bjarmason 2004-12-06 12:16:52 UTC
See the URL testcase.
Comment 1 JeLuF 2004-12-07 22:38:51 UTC
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
Comment 2 JeLuF 2004-12-07 23:12:59 UTC
There's a hint at

To resize an animated GIF, one needs to use '-scale xx%' instead of '-geometry

Have to check how this can be implemented in MediaWiki.
Comment 3 Daniel Kinzler 2006-04-30 14:07:21 UTC
What's the status of this? The problem seems to persist, see
for example, a scaled version of

Is this a bug in ImageMagick, or can it be resolved by tweaking it a bit?
Comment 4 David Benbennick 2006-04-30 19:46:01 UTC
(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.
Comment 5 Yug 2006-04-30 23:58:57 UTC
See the test area : []
Comment 6 Yug 2006-05-01 21:23:42 UTC
Please, may we know when that should be fixe ? (in the week / month / 3 month
?). Thanks~~ 

Comment 7 Daniel Kinzler 2006-05-01 23:07:59 UTC
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

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.
Comment 8 Ilmari Karonen 2006-05-18 17:08:33 UTC
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.
Comment 9 JeLuF 2006-05-28 13:21:14 UTC
Fixed in rev 14433
Comment 10 JeLuF 2006-06-03 13:22:46 UTC
*** Bug 6183 has been marked as a duplicate of this bug. ***
Comment 11 Yug 2006-06-07 19:54:15 UTC
Thanks, thanks, thanks, thanks !
from the little team working on the commons Chinese stroke order project,
and [[Category:Chinese stroke order]]

All the "team" is thanking you :] 

Yug , Wikic, Muke, M4RC0, Ignis ....
Comment 12 Yug 2006-06-07 19:55:17 UTC
[[:commons:Category:Chinese stroke order]]
Comment 13 Ilmari Karonen 2006-09-03 03:04:42 UTC
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.
Comment 14 Ilmari Karonen 2006-09-04 14:17:48 UTC
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
Comment 15 Ilmari Karonen 2006-10-07 23:19:40 UTC
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.
Comment 16 Ilmari Karonen 2006-10-08 00:00:51 UTC
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 = ();
Comment 17 John Reid 2006-10-30 13:56:02 UTC
The bug -- or a closely related one -- may remain. See:

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

I'm going to downgrade this bug. 
Comment 18 Brion Vibber 2007-04-27 18:03:15 UTC
This seems reasonably resolved at this time, and purge should more or less work
these days.

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