All animated GIFs unexpectedly thumbnailed as still images
Closed, ResolvedPublic

Description

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.


Version: unspecified
Severity: major

bzimport added a subscriber: wikibugs-l.
bzimport set Reference to bz22041.
Dragons_flight created this task.Via LegacyJan 7 2010, 1:03 PM
Ilmari_Karonen added a comment.Via ConduitJan 7 2010, 7:18 PM

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.

gpaumier added a comment.Via ConduitJan 7 2010, 7:21 PM

CCing Andrew who wrote the patch about GIF thumbnailing iirc.

Dragons_flight added a comment.Via ConduitJan 7 2010, 10:06 PM

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

bzimport added a comment.Via ConduitJan 12 2010, 12:48 PM

Proofreader77 wrote:

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

TheDJ added a comment.Via ConduitJan 13 2010, 6:16 PM

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.

bzimport added a comment.Via ConduitJan 14 2010, 12:19 AM

zedlightman wrote:

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.

TheDJ added a comment.Via ConduitJan 14 2010, 1:24 AM

all GIF scaling has been disabled again a few hours ago. Purge pages if needed to force redrawing.

bzimport added a comment.Via ConduitFeb 16 2010, 10:29 AM

zedlightman wrote:

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.

bzimport added a comment.Via ConduitMar 1 2010, 1:48 AM

zedlightman wrote:

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.

bzimport added a comment.Via ConduitMar 1 2010, 2:04 AM

zedlightman wrote:

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.

werdna added a comment.Via ConduitApr 6 2010, 4:11 AM

andrew@fenari:~/php-1.5$ php maintenance/eval.php

print $wgMaxAnimatedGifArea

1

Seems like the cause.

I've fixed this.

bzimport added a comment.Via ConduitApr 7 2010, 12:53 AM

zedlightman wrote:

See also Bug 23063:
https://bugzilla.wikimedia.org/show_bug.cgi?id=23063

Gilles added a project: Multimedia.Via WebDec 4 2014, 10:46 AM
Gilles moved this task to Closed on the Multimedia workboard.Via WebDec 4 2014, 10:48 AM
Gilles moved this task to Closed on the Multimedia workboard.

Add Comment