Last modified: 2011-04-28 20:25:08 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 11822 - rescaling of animated gif increase size
rescaling of animated gif increase size
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
File management (Other open bugs)
unspecified
All All
: Normal normal with 2 votes (vote)
: ---
Assigned To: Klaus Stock
: patch, patch-need-review
: 2604 23398 (view as bug list)
Depends on:
Blocks: gif
  Show dependency treegraph
 
Reported: 2007-10-30 23:45 UTC by Carl Fürstenberg
Modified: 2011-04-28 20:25 UTC (History)
9 users (show)

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


Attachments
Patch to resolve excessive size of thumbnails of animated GIfs when using ImageMagick (460 bytes, patch)
2008-05-01 17:17 UTC, Klaus Stock
Details
Updated patch (1.77 KB, patch)
2008-05-19 21:23 UTC, Brion Vibber
Details

Comment 1 Brian Jacobs 2007-10-31 00:02:58 UTC
it's not a bug.  When you use thumb the image is resized to 180px.  The bloat occurs when it's transcoded from original format to 180px; no idea how all that works... maybe since you have the original rastor data you can render it optimally, whereas a resized animation that is deconstructed and reconstructed causes significant bloat.  The fix:  either render it at 180px, or change the type to frame (as I have now done).
Comment 2 Carl Fürstenberg 2007-10-31 14:37:41 UTC
I would say it's a bug when the size is increased 15 times.
Comment 3 Brian Jacobs 2007-10-31 14:59:31 UTC
It may be.  I thought that the act of deconstructing and reconstructing an animated .GIF would be massively more inefficient than re-rendering it (from the vector to the rastor - or maybe i have the terms backwards?) would cause the bloat.  I am not an image/graphics person, and so maybe this shouldn't be.
Comment 4 Ilmari Karonen 2007-10-31 16:12:11 UTC
This problem can be fixed by telling ImageMagick to optimize the animation after scaling.  The only difficulty is that this won't work in very old versions of ImageMagick (where the definition of "very old" depends on which optimization method is chosen).  For more information, see <http://www.imagemagick.org/Usage/anim_opt/>.

An alternative would be to postprocess the scaled animations with a separate program designed specifically for optimizing GIF animations, such as GIFsicle (<http://www.lcdf.org/gifsicle/>).  This would probably produce the best results, but I think this would have to be an optional / Wikimedia-specific change, since we can't really count on all webhosts having GIFsicle installed.

In any case, there is, of course, a simple workaround: (re)upload your animations at the size they're meant to be shown at.  Of course that's not very elegant, but it's what _everyone_ did until about 1.5 years ago (back when the scaling of optimized GIF animation was simply broken and useless).

Anyway, I'll see what I can do to fix this.
Comment 5 Klaus Stock 2008-04-30 13:20:49 UTC
It's a BUG.

Let's have a look into includes/media/Bitmap.php:

			$cmd  =  wfEscapeShellArg($wgImageMagickConvertCommand) .
				" {$quality} -background white -size {$physicalWidth} ".
				wfEscapeShellArg($srcPath) .
				// Coalesce is needed to scale animated GIFs properly (bug 1017).
				' -coalesce ' .
				// For the -resize option a "!" is needed to force exact size,
				// or ImageMagick may decide your ratio is wrong and slice off
				// a pixel.
				" -thumbnail " . wfEscapeShellArg( "{$physicalWidth}x{$physicalHeight}!" ) .
				" -depth 8 $sharpen " .
				wfEscapeShellArg($dstPath) . " 2>&1";


The ImageMagick parameter '-coalesce' de-optimizes the animated GIF. That's okay for the further thumbnail step. However, the result is NOT re-optimized, but saved UN-optimized. I can confirm that a downscale from 320px to 120px can yield a 10-fold increase in file size.

PROPOSED FIX:

			$cmd  =  wfEscapeShellArg($wgImageMagickConvertCommand) .
				" {$quality} -background white -size {$physicalWidth} ".
				wfEscapeShellArg($srcPath) .
				// Coalesce is needed to scale animated GIFs properly (bug 1017).
				' -coalesce ' .
				// For the -resize option a "!" is needed to force exact size,
				// or ImageMagick may decide your ratio is wrong and slice off
				// a pixel.
				" -thumbnail " . wfEscapeShellArg( "{$physicalWidth}x{$physicalHeight}!" ) .
				" -depth 8 $sharpen " .
				' -layers optimize ' .
				wfEscapeShellArg($dstPath) . " 2>&1";

The additional ImageMagick option '-layers optimize ' helps to keep the file size more reasonable. "More reasonable" means that the thumbnail may, in some cases, still have a larger filesize than the original, but at least not very much larger.

Like '-coalesce' it has no effect on other file formats (like PNG). Above code is currently in effect at http://www.c64-wiki.de and http://www.c64-wiki.com (which is still running V1.11.x). Note that similar scaling code can be found in includes/Image.php, which should also be fixed.

Currently, only about half of the animated GIFs at the C64-Wiki have been re-done with the 
'-layers optimize' option, so you may still find some excessivly sized thumbnail files at http://www.c64-wiki.de/index.php/Kategorie:Animation !

- Klaus
Comment 6 Klaus Stock 2008-05-01 17:17:50 UTC
Created attachment 4865 [details]
Patch to resolve excessive size of thumbnails of animated GIfs when using ImageMagick

Fix has no effect on JPG, PNG and non-animated GIFs, verified at the C64-Wiki with Imagegaick 6.4.0.

It feels like the optimization of the animated GIF thumbnails requires more CPU power (that was to be excpected...). OTOH, thumbnails which require 10 or 15 times the storage space and bandwitdh than the original don't really make sense, so investing a little more CPU time into the occassional animated GIF appears to be the right thing to do :-)
Comment 7 Klaus Stock 2008-05-01 17:19:45 UTC
> Note that similar scaling code can be found in includes/Image.php, which should also be fixed.

Forget it, the code in the runk has already been sanitized wrt to Image.php. Only media/Bitmap.php matters.
Comment 8 Klaus Stock 2008-05-01 20:48:51 UTC
> Forget it, the code in the runk has already been sanitized wrt to Image.php.
"runk" = "trunk". Yup, 1337 skillz on da keyboard. I haz them! ;-)


Comment 9 Brion Vibber 2008-05-19 21:23:49 UTC
Created attachment 4906 [details]
Updated patch

Rearranges some code to look nicer to me and only add the extra options for GIFs.

Some issues, however...

The -layers option seems to have come in semi-recently. I get about twice the filesize under ImageMagick 6.2.8 (on our Fedora boxes) as I do on my home box w/ 6.3.8, while the 6.2.4 on our Ubuntu boxes rejects the -layers option outright, failing to scale entirely!

Not good -- this would break every GIF on sites with old ImageMagick. :(

We can upgrade our own copies, but it would be good for MediaWiki to be more careful with these options. It could detect failure and back off, retrying without the 'fancy' options, or do a version check beforehand (potentially slower or less reliable).
Comment 10 Brion Vibber 2008-12-12 23:13:06 UTC
Note our image scaler boxes are currently running ImageMagick 6.3.7... on the other hand we've disabled scaling of GIFs for now due to recurring problems handling GIFs. :P

A version check, or a fallback-on-failure could deal with the versioning issue in general (eg remove the -layers option if it failed to run the first time).
Comment 11 Ilmari Karonen 2010-05-04 12:35:44 UTC
*** Bug 23398 has been marked as a duplicate of this bug. ***
Comment 12 Derk-Jan Hartman 2010-05-04 14:40:09 UTC
I intend on fixing this issue. Do we still think we need backward compatibility with imagemagick before 6.3 ?

ImageMagick 6.3 was first released in October-2006.
Comment 13 Derk-Jan Hartman 2010-05-04 14:47:11 UTC
as a matter of fact, 6.2.7 which is the first to support -layers optimizeplus was already released in May 2006. And 6.2.6 the first release with -layers was released in april of 2006.
Comment 14 Ilmari Karonen 2010-05-05 11:15:54 UTC
Hmm... I see that Ubuntu 6.06 LTS (dapper) still uses IM 6.2.4, and the server version is officially supported until June 2011.  Then again, they also include MW 1.4.  Even Debian stable has IM 6.3.7 these days.

Personally, I think I'd be OK with requiring an ImageMagick version less than four years old.  Although that means I'll have call my webhost and ask them to upgrade -- it seems they're running a mix of 6.2.4 and 6.3.7 on their servers.  Oh well, I should do that anyway.  Or compile my own.
Comment 15 Derk-Jan Hartman 2010-05-05 14:57:23 UTC
After having studied

http://www.imagemagick.org/Usage/video/#gif
http://www.imagemagick.org/Usage/anim_opt/

I have studied the options "-fuzz 10% -layers optimize". This provided reasonable optimization. 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).

I'm also considering splitting animated from non-animated behavior, using png thumbs for non-animated images.
Comment 16 Derk-Jan Hartman 2010-05-05 15:00:27 UTC
For backwards compatibility i'm considering expanding the ImageHandler with a routine to check /opt/local/bin/convert -version  That info should probably be cached in some way, but I don't really have any ideas about that yet.
Comment 17 Max Semenik 2010-06-26 09:17:58 UTC
*** Bug 2604 has been marked as a duplicate of this bug. ***
Comment 18 Derk-Jan Hartman 2010-08-19 10:35:15 UTC
Right this is annoying. Apparently using "-layers optimize" breaks transparency. I have discussed this with an ImageMagick developer, and "This is a know problem, and one that suddenly appeared, but the cause is not known. It appears to effect the first image in a sequence but does not always happen."

So we cannot optimize images and expect transparency to work, though it does seem that the "-layers OptimizeTransparency" option doesn't have this problem as much. I'll try to see if I can figure that out for 100%.

I'll also consider at least adding +map to the images, to keep the colortable reasonable.
Comment 19 Derk-Jan Hartman 2010-08-19 11:53:04 UTC
Confirmed, just using -layer OptimizeTransparency doesn't exhibit this problem, but it was only added in IM v6.3.4-4).

So we could use that, but then we should probably have a sort of version check for imagemagick. I'm not sure how to do something like that in PHP (at least not with it being at all effecient).
Comment 20 Derk-Jan Hartman 2010-08-20 13:38:47 UTC
Should be much improved with r71354.

I'm using OptimizeTransparency, hopefully at some time the normal -optimize is repaired and we can start using that.
Comment 21 Brion Vibber 2011-04-28 00:56:56 UTC
The +map option appears to still damage at least some transparent animated GIFs; see bug 28631.
Comment 22 Mark A. Hershberger 2011-04-28 20:25:08 UTC
Removed the +map bit in r87099

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


Navigation
Links