Last modified: 2010-04-06 06:06:27 UTC
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!
Presumably ImageMagick is being a little overzealous with the alpha channel...
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.
Resolved.
Did you resolve it properly, or in a way that will lead to downtime in the near future?
(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.
You mean for GIFs uploaded after r54284 was deployed? What about GIFs uploaded before that time?
(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.
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.
