Currently, server side GIF thumbnailing on Wikimedia sites is disabled entirely by setting $wgMediaHandlers['image/gif'] = 'BitmapHandler_ClientOnly';
This causes all GIF files to be send to the browser at original size regardless of what size has been requested.
While most folks seem to have pretty much resigned to the fact that animated GIFs can't be thumbnailed -- it never worked very well to begin with -- the fact that even static GIFs are sent at full resolution remains somewhat annoying, especially since people have uploaded some extremely large bitmaps in GIF format in the past.
It seems to me that delivering *static* thumbnails of GIF images, either in GIF or PNG format, would be a considerable improvement over the current situation. And indeed, the code to do that seems to be already in place: just set $wgMaxAnimatedGifArea = 0;
So, my questions would be:
1. Is there a reason we don't do this already?
2. If yes, and the reason is the GIF encoding causes too much load, would thumbnailing GIFs to PNG be better? It should only take a few lines of code to change the output format.
3. Alternatively, if the problem is ImageMagick taking too much time to read animated GIFs even just to extract only the first frame, would some other scaling program be better? Indeed, it should even be possible to write a bit of PHP code to pull out just the first frame of a GIF file and hand it off to ImageMagick for scaling.
Ps. I'd also like to take the opportunity to remind everyone of the existence of https://bugzilla.wikimedia.org/show_bug.cgi?id=16451 and of the excellent-looking patch Werdna has written for it. We can do a _lot_ better with GIfs that we're currently doing.
2009/8/2 Ilmari Karonen nospam@vyznev.net:
It seems to me that delivering *static* thumbnails of GIF images, either in GIF or PNG format, would be a considerable improvement over the current situation. And indeed, the code to do that seems to be already in place: just set $wgMaxAnimatedGifArea = 0; So, my questions would be:
- Is there a reason we don't do this already?
Careful to only do it if in fact definitely scaling. Animated GIFs are in use on lots of page on en:wp, for instance, when there's reason to put a small animation right there on the page rather than a click away.
- Alternatively, if the problem is ImageMagick taking too much time to
read animated GIFs even just to extract only the first frame, would some other scaling program be better? Indeed, it should even be possible to write a bit of PHP code to pull out just the first frame of a GIF file and hand it off to ImageMagick for scaling.
ImageMagick is a Swiss army knife - it does everything and isn't the best at anything. I would be unsurprised if there was a tool to do this specific job much better.
- d.
On 8/2/09 7:26 AM, Ilmari Karonen wrote:
It seems to me that delivering *static* thumbnails of GIF images, either in GIF or PNG format, would be a considerable improvement over the current situation. And indeed, the code to do that seems to be already in place: just set $wgMaxAnimatedGifArea = 0;
So, my questions would be:
- Is there a reason we don't do this already?
IIRC, we don't yet have working detection for animated GIFs: https://bugzilla.wikimedia.org/show_bug.cgi?id=16451
Looks like Andrew put together an updated patch a couple months ago but didn't have a chance to test and confirm it was working properly. Anyone care to take a peek?
-- brion
On 02/08/2009, at 5:36 PM, Brion Vibber wrote:
Looks like Andrew put together an updated patch a couple months ago but didn't have a chance to test and confirm it was working properly. Anyone care to take a peek?
I can possibly poke this tomorrow, must have slipped through my fingers on Bug Friday :)
-- Andrew Garrett agarrett@wikimedia.org http://werdn.us/
On Sun, Aug 2, 2009 at 9:38 AM, Andrew Garrettagarrett@wikimedia.org wrote:
I can possibly poke this tomorrow, must have slipped through my fingers on Bug Friday :)
Well it was assigned to you and you unassigned it from yourself...
-Robert Rohde
Brion Vibber wrote:
On 8/2/09 7:26 AM, Ilmari Karonen wrote:
It seems to me that delivering *static* thumbnails of GIF images, either in GIF or PNG format, would be a considerable improvement over the current situation. And indeed, the code to do that seems to be already in place: just set $wgMaxAnimatedGifArea = 0;
IIRC, we don't yet have working detection for animated GIFs: https://bugzilla.wikimedia.org/show_bug.cgi?id=16451
That shouldn't matter, should it? Setting $wgMaxAnimatedGifArea to N simply causes Bitmap.php to tell ImageMagick to only extract the first frame of any GIF files with N or more pixels (which makes no difference if the GIF in fact only has one frame).
On Sun, Aug 2, 2009 at 10:26 AM, Ilmari Karonennospam@vyznev.net wrote: [snip]
It seems to me that delivering *static* thumbnails of GIF images, either in GIF or PNG format, would be a considerable improvement over the current situation. And indeed, the code to do that seems to be already in place: just set $wgMaxAnimatedGifArea = 0;
So— separate from animation why would you use an gif rather than a PNG? I can think of two reasons:
(1) you're making a spacer image and the gif is actually smaller, scaling isn't relevant here (2) you're using gif transparency and are obsessed with compatibility with old IE. Scaling doesn't tend to work really well with binary transparency.
In other cases the gif tends to be larger, loads slower, etc. They can be converted to PNG losslessly, so you should probably do so. What am I missing?
On Sun, Aug 2, 2009 at 1:33 PM, Gregory Maxwellgmaxwell@gmail.com wrote:
In other cases the gif tends to be larger, loads slower, etc. They can be converted to PNG losslessly, so you should probably do so. What am I missing?
That a lot of people don't know the above and upload GIFs anyway, and until we can fix all users of each of these images, it would be nice to not serve the full-size file all the time. (Anyone want to make the planned transcode-on-upload infrastructure work for images too? :) )
Aryeh Gregor wrote:
On Sun, Aug 2, 2009 at 1:33 PM, Gregory Maxwellgmaxwell@gmail.com wrote:
In other cases the gif tends to be larger, loads slower, etc. They can be converted to PNG losslessly, so you should probably do so. What am I missing?
That a lot of people don't know the above and upload GIFs anyway, and until we can fix all users of each of these images, it would be nice to not serve the full-size file all the time. (Anyone want to make the planned transcode-on-upload infrastructure work for images too? :) )
Also, Commons alone has almost a hundred thousand existing GIF files. Converting them all to PNG would be a significant job, especially since changing the format (and thus the suffix) means that they can't just be reuploaded under the same title.
(Which means you have to copy the description page and the old upload history, update links on all other projects, give any non-Wikimedia projects using ForeignAPIRepo time to update their links and hope that they actually do so, and even after you've done all that, it *still* ends up messing with watchlists, user contribution histories and old article versions because there's no way to update those. Eugh.)
On Sun, Aug 2, 2009 at 8:20 PM, Ilmari Karonennospam@vyznev.net wrote:
Aryeh Gregor wrote:
On Sun, Aug 2, 2009 at 1:33 PM, Gregory Maxwellgmaxwell@gmail.com wrote:
In other cases the gif tends to be larger, loads slower, etc. They can be converted to PNG losslessly, so you should probably do so. What am I missing?
That a lot of people don't know the above and upload GIFs anyway, and until we can fix all users of each of these images, it would be nice to not serve the full-size file all the time. (Anyone want to make the planned transcode-on-upload infrastructure work for images too? :) )
Also, Commons alone has almost a hundred thousand existing GIF files. Converting them all to PNG would be a significant job, especially since changing the format (and thus the suffix) means that they can't just be reuploaded under the same title.
Or we just get rid of extensions all together, as mentioned in another thread.
Bryan
Going back a bit in the thread history,
Ilmari Karonen wrote:
Also, Commons alone has almost a hundred thousand existing GIF files. Converting them all to PNG would be a significant job, especially since changing the format (and thus the suffix) means that they can't just be reuploaded under the same title.
(Which means you have to copy the description page and the old upload history, update links on all other projects, give any non-Wikimedia projects using ForeignAPIRepo time to update their links and hope that they actually do so, and even after you've done all that, it *still* ends up messing with watchlists, user contribution histories and old article versions because there's no way to update those. Eugh.)
I'm not very familiar image files, but....
Doesn't move work with image description pages? What would it take to move the histories and update the watch lists?
Doesn't redirect work with images? What would it take?
Assuming that the above work, that would handle the old article versions.
On Mon, Aug 3, 2009 at 1:32 PM, William Allen Simpsonwilliam.allen.simpson@gmail.com wrote:
Going back a bit in the thread history,
Ilmari Karonen wrote:
Also, Commons alone has almost a hundred thousand existing GIF files. Converting them all to PNG would be a significant job, especially since changing the format (and thus the suffix) means that they can't just be reuploaded under the same title.
(Which means you have to copy the description page and the old upload history, update links on all other projects, give any non-Wikimedia projects using ForeignAPIRepo time to update their links and hope that they actually do so, and even after you've done all that, it *still* ends up messing with watchlists, user contribution histories and old article versions because there's no way to update those. Eugh.)
I'm not very familiar image files, but....
Doesn't move work with image description pages? What would it take to move the histories and update the watch lists?
Doesn't redirect work with images? What would it take?
Assuming that the above work, that would handle the old article versions.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
I know image redirecting was enabled briefly then disabled due to some issues found during the process. Those have all been fixed (afaik). Was this re-enabled on WMF?
-Chad
On Mon, Aug 3, 2009 at 7:59 PM, Chadinnocentkiller@gmail.com wrote:
I know image redirecting was enabled briefly then disabled due to some issues found during the process. Those have all been fixed (afaik). Was this re-enabled on WMF?
Image redirecting is working. Image moving is currently working but not enabled.
Bryan
Gregory Maxwell wrote:
(2) you're using gif transparency and are obsessed with compatibility with old IE. Scaling doesn't tend to work really well with binary transparency.
By the way, forgot to mention this earlier, but this is actually a very good argument in favor of outputting thumbnails of GIFs in PNG format.
On Sun, August 2, 2009 14:25, Ilmari Karonen wrote:
Gregory Maxwell wrote:
(2) you're using gif transparency and are obsessed with compatibility with old IE. Scaling doesn't tend to work really well with binary transparency.
By the way, forgot to mention this earlier, but this is actually a very good argument in favor of outputting thumbnails of GIFs in PNG format.
Actually, I think this is a good opportunity to start thinking about animated GIFs in terms of video instead of animated images. (I'm thinking low-FPS Theora.)
Cheers, George / User:GChriss
-- Ilmari Karonen
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
wikitech-l@lists.wikimedia.org