Last modified: 2010-04-07 00:53:22 UTC
Recently thumbnailing of GIFs was re-enabled on Wikimedia sites after new code was added to count the frames in animated GIFs. Reading the code it appears that currently two checks are intended to determine whether a GIF should be thumbnailed. First, if height*width*frames > $wgMaxImageArea then Bitmap.php aborts and no thumbnail is attempted. Secondly, if height*width > $wgMaxAnimatedGifArea then Bitmap.php returns only the first frame. The default values for these parameters are 12.5 million and 1 million respectively, and they do not appear to have been changed in Wikimedia's CommonSettings.php file. Now there appear to be two issues here. First, since we are now counting GIF frames, is there a reason for still having the second check? My understanding is that the lower limit was added in the days before frame counting to trap large animated GIFs with many frame before they could crash the thumbnailer. Now that we count frames, isn't the first check sufficient for that? Secondly, and the more immediate reason for this bug report, it appears that Wikimedia is showing single frames for some animated GIFs even if their size is definitely less than one megapixel. For example: http://en.wikipedia.org/wiki/File:Phenakistoscope_3g07690a.gif http://en.wikipedia.org/wiki/File:Swimapod4.gif http://commons.wikimedia.org/wiki/File:Action_potential_propagation.gif Each of these is an animated GIF with an area less than 1 megapixel but the thumbnails shown on the image description page (and anywhere else thumbnails appear) show only a still image. Hence they appear to have triggered the second conditional even though they shouldn't have if the sizes are being accurately handled and the limit is still set at the default.
If the checks currently work as you say, then I agree that it seems a bit backwards. It would seem much more logical for the decision whether to scale the whole animation, or just the first frame, to be based on the total size of all the frames combined, while the decision whether to scale even the first frame should logically only depend on the size of that frame. According to your description, it's currently the other way around, which makes no sense to me.
CCing Andrew who wrote the patch about GIF thumbnailing iirc.
After further investigation it appears that this issue is affecting all or nearly all thumbnails created from animated GIFs since the software update. Initially only a portion of images seemed to be affected, but that seems to have been an artifact of the sporadic distribution of whatever process(es) were running around updating thumbnails. Using the purge function to force thumbnail updates appears to show that all new attempts to thumbnail animated GIFs are resulting in only the first frame being selected. Hence entire categories of animated GIFs are being silenced: http://commons.wikimedia.org/wiki/Category:Animations_of_standing_waves http://commons.wikimedia.org/wiki/Category:Drum_vibration_animations
Regarding: http://en.wikipedia.org/wiki/File:Phenakistoscope_3g07690a.gif To test what was happening about size etc, I made a much reduced size image, http://en.wikipedia.org/wiki/File:Phenakistoscope_small_animation.gif but that one froze, too, when I tried to display it with "px" specification. The only way I could get it to display without freezing was to upload an image that was exactly the size that was needed. (I.E., if you used "px" at all, the image froze.)
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.
Is there someone who can enable static GIF scaling, and disable only animated GIF scaling? Please see: http://commons.wikimedia.org/wiki/Commons:Graphics_village_pump#Some_animated_GIFs_inappropriately_shown_as_still_images and the preceding discussion.
all GIF scaling has been disabled again a few hours ago. Purge pages if needed to force redrawing.
Please see: http://commons.wikimedia.org/wiki/Commons:Graphics_village_pump#Can_static_GIF_scaling_be_separated_from_animated_GIF_scaling.3F See also bug #22505. Various animated GIF scaling problems have existed for years. There is no need for static GIF resizing to be turned off though. There are problems doing without properly-scaled static GIF images. For example; the blurry browser resizing of these GIF images: http://commons.wikimedia.org/wiki/Category:Octave_Uzanne There are also many charts, graphs, tables, diagrams, and graphics of all kinds in the GIF format. They use a lot of bandwidth in image categories. They use more kilobytes in articles.
Proofreader77 wrote: "The only way I could get it to display without freezing was to upload an image that was exactly the size that was needed. (I.E., if you used "px" at all, the image froze.)" This is how animated GIF images were put in wikipedia articles for a long time. Any GIF scaling is better than none. At least as concerns static GIF images. So I suggest turning the GIF scaling back on even if it converts animated GIFs into static-image thumbs when scaling is attempted with "px" being added. For more explanation why please see: http://commons.wikimedia.org/wiki/Commons:Graphics_village_pump#Any_GIF_scaling_is_better_than_none See also: *http://en.wikipedia.org/wiki/Retreat_of_glaciers_since_1850#Oceania *http://en.wikipedia.org/wiki/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. A low-kilobyte static image is an improvement. It is better that people go back to the old method for inserting the animated GIF in a Wikipedia article. IE, creating the specific size. Derk-Jan Hartman wrote: "There have been 5 threads about this on VP/T already. Better no thumbs I think." Those VP/T threads have been asking that the thumbnailing be turned on, and not off. Those threads are linked from the Graphics Village Pump links in my comments.
OK. I see that we are referring to 2 different Village Pumps: http://commons.wikimedia.org/wiki/Commons:Graphics_village_pump http://en.wikipedia.org/wiki/Wikipedia:Village_pump_%28technical%29 Some of the Wikipedia VP/T animated-GIF threads are archived here: http://en.wikipedia.org/wiki/Wikipedia:Village_pump_%28technical%29/Archive_69 I think we are telling people the wrong solution in those threads. It may be better to tell people to create specifically-sized animated GIFs. Those will always work.
andrew@fenari:~/php-1.5$ php maintenance/eval.php > print $wgMaxAnimatedGifArea 1 Seems like the cause. I've fixed this.
See also Bug 23063: https://bugzilla.wikimedia.org/show_bug.cgi?id=23063
