Commons:Graphics village pump/GIF thread
Perpetual GIF resizing complaint thread (issue still unresolved) 
Animated GIF resizing. Last.fm resizes them. Why not MediaWiki? 
Has there been any progress with this? Why can't MediaWiki correctly resize animated gif images?
Here is a last.fm animated gif linked below. I found it today. Note that correctly resized animated images are showing up on last.fm pages:
- http://www.last.fm/user/Inci90 - largest size. 55 kilobytes.
- http://www.last.fm/user/Inci90/library - smallest size. 8 kilobytes.
- http://www.last.fm/music/Cluster/+shoutbox - medium size. 20 kilobytes. The Inci90 avatar is currently next to the third comment.
There are many animated GIF images on the Commons. For example;
Note that the full kilobytes used for the full-size image is downloaded for the thumbs. It causes some categories to take a long time to load due to all the full-size GIF animations having to load. I have broadband, and so they usually eventually finish loading. It can take a long time even on broadband. It must be an extra load on the servers.
A full category of animated thumbnail images will not finish loading for most dialup users unless they wait a very long time. It deprives them of looking at the thumbnails to decide if they want to use any of the animated images. It deprives them of static images too if they happen to be in a category page with many animated images. --Timeshifter (talk) 02:58, 20 October 2009 (UTC)
- It just hasn't been a priority for developers, since a workaround exists (offline resizing). Dcoetzee (talk) 06:01, 20 October 2009 (UTC)
- Offline resizing does not solve the thumbnail problem. Look at Category:Animations of geometry. All the images in that category are animated images. All the animated-GIF thumbnails are created by downloading the full-size animated-GIF images, and then resizing them in the browser. This is a huge download, and a huge waste of server time and bandwidth. It wastes money too. It also makes the animated images inaccessible to many dialup users. It also makes some static images inaccessible too if there are static images mixed up with a lot of animated images in a category. --Timeshifter (talk) 15:53, 20 October 2009 (UTC)
- Bugzilla's bug #16451 GIF scaling limit should be applied to animated GIFs only is marked as fixed as of 2009-08-14. --Jarekt (talk) 21:03, 22 October 2009 (UTC)
- I left a request for implementation at COM:AN here:
- Commons:Administrators' noticeboard/Archive 18#Animated GIF resizing bug. Fix awaits implementation by admin
- --Timeshifter (talk) 16:45, 12 November 2009 (UTC)
GIF scaling (animated and non-animated) still not working 
- It seems that all GIFs (animated and non-animated) are not being scaled by MediaWiki. I thought the problem was resolved according to the Bugzilla bug thread: #16451 GIF scaling limit should be applied to animated GIFs only. A 2009-08-14 comment by Andrew Garrett in that thread says it is fixed. His user page is en:User:Werdna.
- New people reading this topic need to look above at the previous talk section also in order to understand the history more fully.
- See also the later Bugzilla thread comment by Robert Rohde (en:User:Dragons flight):
- He says the fix can be implemented by removing this from CommonSettings.php:
// Disable server-side GIF scaling
$wgMediaHandlers['image/gif'] = 'BitmapHandler_ClientOnly';
This whole episode has been ultra-lame from beginning to end 
This whole thing has been stupidly handled from the beginning -- when problems with a small minority of animated GIFs was allowed to indefinitely suspend the usefulness of ALL GIFs, despite the fact that there has been no effort made over the last five years to fix the well-known grave inefficiencies of Wikimedia PNG resizing (inefficiencies which were what drove many people to upload GIFs instead of PNGs in the first place) -- down to the present, when over FOUR MONTHS after a fix was offered, it still hasn't been put in place, apparently because no one with proper authority is willing to take responsibility, or even wants to be bothered at all. With proper management and active followup, this whole thing could have been a two-weeks' episode, instead of which it has dragged on TWO YEARS, partly because nobody in the developers cabal seems to take problems of image resizing very seriously -- even though such problems can have a strong effect on the user experience of people browsing Wikipedia, and the amount of bandwidth served by the Wikimedia Foundation servers... AnonMoos (talk) 18:51, 20 December 2009 (UTC)
- I agree. I also think overwork has something to do with it. The Wikimedia Foundation needs to prioritize more money to pay developers to fix the over 4000 bugs listed in the Bugzilla Weekly Reports. Instead of spending as much money for lesser-needed things the Wikimedia Foundation is trying to do. --Timeshifter (talk) 21:13, 20 December 2009 (UTC)
- Well, it seems like fixing it is being given "after dog-wash" priority (as such a situation is referred to in the Jargon File ) even though leaving it unfixed has a variety of negative consequences, such as rendering categories like Category:Octave Uzanne basically useless in their intended function of displaying the images that belong to the category... AnonMoos (talk) 03:45, 27 December 2009 (UTC)
- Yeah, I don't get it. Especially considering how easy the fix is. 2 lines have to be removed from a settings file. It looks like the relevant bugzilla page is now this one:
- https://bugzilla.wikimedia.org/show_bug.cgi?id=20312 --Timeshifter (talk) 07:36, 1 January 2010 (UTC)
Even artists use animated GIFs 
Wikia GIF scaling is working 
I searched Wikia.com for animated GIFs:
Here are some results of that search:
Compare the thumbnail and full-size versions of the images. GIF scaling is working. For example:
- http://halo.wikia.com/wiki/File:1217685012_Reallyhighskyjack.gif - 1.55 megabytes.
- thumbnail of same image at 175 kilobytes. --Timeshifter (talk) 12:37, 4 January 2010 (UTC)
Oh frabjous day! 
- Woohoo! The difference at http://commons.wikimedia.org/wiki/Category:Octave_Uzanne is striking. Before it was a mass of disjointed, almost unintelligible dots in each thumbnail image. Now the thumbnails are much clearer images.
- Also, the category page loads very fast now. The thumbnails use around 10 kilobytes each. If you are using the Firefox browser, there is a bug with some of the later versions. Right-clicking a thumbnail on a category page, and then clicking "view image info", may give the size of the invisible background image (0.1 kilobytes), and not the kilobytes used by the actual thumbnail image. Save the thumbnail image to see the actual size in kilobytes of the thumbnail. Or look at the category in MS Internet Explorer.
- It looks like Roan Kattouw figured out how to correctly enable GIF scaling yesterday on all wikimedia projects. With some difficulty. See
- Thanks, Roan Kattouw!
- I hope the Wikimedia Foundation rewards our MediaWiki developers. Both the paid staff and the volunteers. Maybe pay bounties for bug fixes and implementations? Is that happening already? And hire more developers now that this latest fundraising campaign is over. --Timeshifter (talk) 07:22, 5 January 2010 (UTC)
- Wow, I replaced a GIF with a PNG the very day before because it resized so hideously. Never again. Well done. ¦ Reisio (talk) 16:17, 6 January 2010 (UTC)
- This is an exciting fix with a substantial practical impact. Great work to Roan and the other devs. Dcoetzee (talk) 00:23, 7 January 2010 (UTC)
Animated GIF scaling now working on all Wikimedia projects 
For example; see the full-size version:
- File:Rotationskoerper animation.gif - 607 kilobytes.
and the 124-kilobyte thumbnail:
The difference in kilobytes due to correct image scaling, is most noticeable when large animated images are scaled to much smaller sizes as in the above example.
- Category:Biology animations
- Category:Animations of geometry
- Category:3D animations
- Category:2D machinery animations
- Category:Abstract Animation
- Category:Very large GIF files
Some animated GIFs inappropriately shown as still images 
- This is strange, see for example Category:Animations of vibrations and waves. All thumbs should show animation, but often the thumbs don't (sometime with very similar .gifs working correctly, see Category:Drum vibration animations). /Pieter Kuiper (talk) 14:39, 7 January 2010 (UTC)
- It might be useful to see how animated GIF scaling is being done elsewhere. Maybe some solutions can be found by adapting the GIF scaling code other sites are using. For example; look at what Last.fm is using for the scaling of their animated GIF avatars to various sizes. See my previous info and links higher up at:
- #Animated GIF resizing. Last.fm resizes them. Why not MediaWiki?
- Maybe a staffer at Last.fm can help out, or open up their code to MediaWiki developers. --Timeshifter (talk) 15:01, 7 January 2010 (UTC)
- I agree. Scaling of static GIFs is still working as I write this. As an experiment I downloaded one large 4 megabyte animated GIF image that wasn't showing in animated form on the category page (Category:Animations of vibrations and waves). See File:Deep water wave.gif.
- I looked up animated GIF resizers in Google, and picked this freeware program to download:
- It is only 628 kilobytes. It does not require installation. Just download it to your hard drive, and click GiFResizer.exe to launch it. Browse to File:Deep_water_wave.gif on your hard drive, and enter 120 pixels in the width spot of the GIF Resizer window. Put a checkmark in "good quality (slower)" box, and click "Resize." It takes a full minute to resize the 4 megabyte file at 390 pixels wide to 730 kilobytes at 120 pixels wide.
- Maybe Mediawiki developers can adapt some of the code. --Timeshifter (talk) 16:56, 7 January 2010 (UTC)
- A solution that takes a minute to rescale a file is, unfortunately, not going to be anywhere near acceptable for on-demand scaling like MediaWiki does it. In any case, modern versions of ImageMagick can rescale GIF animations just fine, if you use the right options. The only problem is that scaling large animations inevitably tends to be slow. (Also, there used to be some issues with older ImageMagick versions not supporting the options needed to output optimized GIF animations, but it's been long enough that most people have probably upgraded by now.) —Ilmari Karonen (talk) 19:35, 7 January 2010 (UTC)
(unindent) OK. After Google searching the ImageMagick.org site I found this:
I see more fully what a vastly complex project it is to do quality scaling of animated GIFs. Utmost respect to MediaWiki developers who manage to implement something that will work adequately well in such an intensive environment as Wikipedia and its serving up of pages and images to 300 million visitors a month.
I hope that static GIF scaling is not sacrificed due to problems with animated GIF scaling. Maybe we can turn off scaling for animated GIFs, and just show scaled static thumbnails of animated GIFs. At least for those animated GIFs that are too difficult to fully scale by Mediawiki on the Commons.
Does Mediawiki cache the scaled, thumbnail-size, animated GIFs? I hope Mediawiki isn't recreating them every time somebody goes to a category with some animated GIFs. One thing I learned from GiFResizer.exe is that even smaller animated GIFs (smaller in kilobytes) still take 5 or 6 seconds to scale down to 120-pixel-wide, category-ready thumbnails. --Timeshifter (talk) 20:21, 7 January 2010 (UTC)
GIF scaling is gone again 
Can static GIF scaling be separated from animated GIF scaling? 
Static GIF scaling works fine. Why not separate it from animated GIF scaling?
See Category:Octave Uzanne. It looks terrible now. It looked great before static GIF scaling was turned off due to the animated GIF problems in other categories. --Timeshifter (talk) 18:18, 31 January 2010 (UTC)
- That's what I've been wondering for years. If the developers in general took resizing problems seriously, then it would have been done long ago. AnonMoos (talk) 22:36, 31 January 2010 (UTC)
There was kind of a statement at en:Wikipedia:Wikipedia_Signpost/2010-01-18/Technology_report... AnonMoos (talk) 15:12, 3 February 2010 (UTC)
- Here it is:
- GIF image scaling. Due to very large animated GIF images crashing the server that makes the thumbnails, the scaling of all GIF images had been disabled for the past months. This was not optimal of course, and new code to detect animated GIF images and decide whether they were potentially too large, was added to the software some time ago. On January 4, these changes were deployed. For reasons not yet understood, all thumbnails of all animated GIFs became stills. This was not the intention, and on January 13 the changes were undone, awaiting analysis of the problem. See also bugzilla:22041.
- This is interesting and possibly related: "On January 11, Wikimedia reached 10Gb/s of Internet traffic for the first time. See the foundation mailing list."
- Wikimedia functions on a very limited budget relative to its Alexa trafic ranking of around 5 or 6. Only a few other sites get more daily page views. So the good Wikimedia-industrial-information complex (kind of like the Military-industrial complex) is straining due to being overextended in its battle against the forces of the evil Spin-industrial-information complex (mainstream media). OK, I will stop the good and evil stuff. :)
- Anyway, there is a lack of enough hardware, technical staff, developers, and especially, funding. According to bugzilla:22041 the main developer working on animated GIF scaling was unavailable at the time of some of those postings in the bugzilla thread.
- "Since werdna doesn't have the time atm, and roan apparently is on a plane, it is probably better to revert the animated GIF changes until someone who understands the code can fix it. There have been 5 threads about this on VP/T already. Better no thumbs I think."
- He is Andrew Garrett in another bugzilla thread, and his user page is en:User:Werdna.
- Wikimedia needs to hire more developers and/or pay rewards to volunteers for successful bug fixes. --Timeshifter (talk) 16:01, 3 February 2010 (UTC)
(Unindent) I started a bugzilla thread:
Can static and animated GIF scaling be separated?
Any GIF scaling is better than none 
I think it may have been a mistake to turn off the GIF scaling due to the problem of it making some animated GIFs into static GIFs when scaled.
- en:Retreat of glaciers since 1850#Oceania
- en:Retreat of glaciers since 1850#Andes and Tierra del Fuego
There are a couple, almost 1-megabyte animated GIFs in those sections. It makes no sense to make dialup users have to wait minutes to see a page.
I think it makes more sense for now to go back to the old method of creating reduced-size, animated GIFs specifically for Wikipedia articles. Then link to the full-size animated GIF images on the Commons.
- I agree. Please someone revert the earlier reversion, and restore the incomplete but preferable scaling of GIFs. After having problems looking at some categories now I started moving large GIFs to sepcial categories with the NOGALLERY magic word, but I feel that job needs to be automated, or maybe a bot devised that creates thumbnails and uploads them to Commons, referring what Timeshifter suggests. So, please restore the scaling, and we can deal with the inappropriate still images separately. -84user (talk) 13:49, 6 March 2010 (UTC)
- I guess the developers are overwhelmed. Maybe the 2 million dollar donation from Google will help:
- See also: https://bugzilla.wikimedia.org/show_bug.cgi?id=22041
- --Timeshifter (talk) 17:42, 10 March 2010 (UTC)
Wikipedia:Village pump (technical) thread started 
See en:Wikipedia:Village pump (technical) and the discussion there about static GIF image resizing by MediaWiki. It seems Bug 22041 and the related GIF bugs are being ignored by the developers (again). --Timeshifter (talk) 18:52, 30 March 2010 (UTC)