Resizing of Some GIFs Rendering Poorly; Setting Needs Changing?
Closed, ResolvedPublic

Description

Author: yegg

Description:
The resizing of images for thumbnails generally works great, but for some reason it does not for a small subset of images. This subset seems to be GIF images with large transparent backgrounds, e.g. logos. When they are being resized, some of the foreground is being dropped. This dropping does not occur if you resize in Photoshop. Could it be that a simple change in setting is needed?

Example: http://upload.wikimedia.org/wikipedia/en/thumb/8/8e/Techcrunch.gif/100px-Techcrunch.gif

It is not a deficiency of GIFs in this case. That is, it can be resized correctly. I did the following one in Photoshop (still transparent): http://en.wikipedia.org/wiki/Image:Techcrunch-transparent-photshop.gif

Reference discussion: http://en.wikipedia.org/wiki/Wikipedia_talk:Preparing_images_for_upload#Resizing_of_Some_GIFs_Rendering_Poorly.3B_Setting_Needs_Changing.3F

Please help!


Version: unspecified
Severity: enhancement

bzimport added a subscriber: wikibugs-l.
bzimport set Reference to bz13252.
bzimport created this task.Via LegacyMar 4 2008, 10:11 PM
brion added a comment.Via ConduitMar 4 2008, 10:51 PM

Presumably ImageMagick is being a little overzealous with the alpha channel...

Edokter added a comment.Via ConduitNov 27 2008, 3:24 PM

From the server admin log:

November 6
21:03 Tim: switched GIFs to use Bitmap_ClientOnly (client-side scaling)
17:23 brion: restarting apache on srv47, seem smysteriously stuck
17:15 brion: setting $wgMaxAnimatedGifArea to 1 to prevent animated thumbnailing of GIFs for now, see if that helps
17:10 brion: river complaining of image scaler issues -- load spikes, depooling?

This is bad news and there were no followups in the log. I really hope this will be fixed soon.

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

Resolved.

tstarling added a comment.Via ConduitApr 6 2010, 5:43 AM

Did you resolve it properly, or in a way that will lead to downtime in the near future?

werdna added a comment.Via ConduitApr 6 2010, 5:50 AM

(In reply to comment #4)

Did you resolve it properly, or in a way that will lead to downtime in the near
future?

I resolved it by turning GIF scaling back on, and setting $wgMaxAnimatedGifArea to its original value.

This won't lead to downtime in the near future, because Bitmap.php uses getImageArea() to find the area to compare with $wgMaxImageArea. In GIF.php, getImageArea() now returns width * height * frame count. This should stop long or big GIFs from being thumbnailed.

tstarling added a comment.Via ConduitApr 6 2010, 5:54 AM

You mean for GIFs uploaded after r54284 was deployed? What about GIFs uploaded before that time?

werdna added a comment.Via ConduitApr 6 2010, 5:56 AM

(In reply to comment #6)

You mean for GIFs uploaded after r54284 was deployed? What about GIFs uploaded
before that time?

I don't follow – are you saying that the metadata won't have been generated for GIFs uploaded before that time? That's a good point, I hadn't thought of that. I could probably fix it, though.

tstarling added a comment.Via ConduitApr 6 2010, 6:06 AM

Yes that's what I was saying, but the facts appear to be even worse than that. None of the 30k GIF files in enwiki have valid metadata.

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

Add Comment