Last modified: 2013-11-11 11:28:11 UTC
If Google's WebP format increases in popularity (eg with rumored default support in future versions of Chrome), it could be advantageous to support generating thumbnails in WebP as an alternative to JPEG; WebP images can generally fit the same quality into a smaller filesize, which cuts down on bandwidth usage and download times. In the ideal case, WebP images should be shipped out on-demand to any browser that declares support for them. The biggest difficulty would be in getting content-type negotiation working for image fetches for anonymous page views! Ah, caching. ;) But even as an option that triggers only for logged-in users, it's something to think about.
Provisionally LATER-ing this; if anybody wants to actively work on it before WebP is a little more imminent, pick it up and open it.
http://www.mediawiki.org/wiki/Manual:$wgThumbLimits defines a list of sizes a registered user can chose from. At least for those who are logged in, we already have a tool to deliver different thumbnails. Could we skip this difficulty of getting content-type negotiation working if we just had one or two default thumbnail sizes in WebP file format?
That'll be the quickest way to get it implemented, but we get the most bang for our buck if it's automatic. One downside as a user pref: do *all* your browsers support webp?
(In reply to comment #3) > That'll be the quickest way to get it implemented, but we get the most bang for > our buck if it's automatic. > Chosing this path does not mean we discard any other. Apart from that, I agree. > One downside as a user pref: do *all* your browsers support webp? Right now, there is no browser supporting WebP. There is a javascript hack out there that modifies webp files in a way to make the browser handle it as a WebM video, therefor displaying it. It works on Firefox, Chrome and Opera.
(In reply to comment #4) > (In reply to comment #3) > > That'll be the quickest way to get it implemented, but we get the most bang for > > our buck if it's automatic. > > > > Chosing this path does not mean we discard any other. Apart from that, I agree. The main reason to implement it at all is to reduce bandwidth usage; as a per-user option it's a geek curiosity, while as a default that can act on all requests it would actually be able to have wide effect. > > One downside as a user pref: do *all* your browsers support webp? > > Right now, there is no browser supporting WebP. There is a javascript hack out > there that modifies webp files in a way to make the browser handle it as a WebM > video, therefor displaying it. It works on Firefox, Chrome and Opera. Well, here's the scenario I was thinking of: a) user enables WebP thumbnails while logged in via Chrome-next b) later, user logs into site from another computer running a different browser, and can't see any thumbnails on the site. That browser might be a netbook, tablet, e-reader, smartphone, game console, or a computer that doesn't have any WebP-capable browser. On the other hand if what the user option is for is to enable an Accept-header check which determines which format gets used, then that's probably not a problem -- that next login would use JPEG thumbnails.
(In reply to comment #5) > Well, here's the scenario I was thinking of: > > a) user enables WebP thumbnails while logged in via Chrome-next > > b) later, user logs into site from another computer running a different > browser, and can't see any thumbnails on the site. That browser might be a > netbook, tablet, e-reader, smartphone, game console, or a computer that doesn't > have any WebP-capable browser. I might have come up with another early approach that will prevent this scenario. 1. A customized user skin .js/.css file to alter any thumbnail linkn(every <img> link to a .jpg that starts with http://upload.wikimedia.org/wikipedia/commons/thumb/) to another url, possibly toolserver.org or webptest.whateverdomain.tld) to ask the browser to get the image from this site. 2. The js could containt a browser switch. Browser not supporting webp would not get the altered url. If someone installs the user-mod and changes browsers, there would not be the undesirable result you described.
Current Status: Google Chrome (stable) and the current stable Opera Web Browser now support WebP encoded image files. In en.wikipedia.org, a test script exists that replaces jpeg thumbnails with a (toolserver generated) WebP image. Add: importScript('User:Magnus Manske/webp.js'); into your user specific .js file (such as User:[Name]/vector.js)
[Reopening to get rid of deprecated LATER resolution.]
If you implement hosting dual format webp/jpg this will contribute for web advance, because actually this is pre-condition of mozilla to support webp in farifex. See: https://bugzilla.mozilla.org/show_bug.cgi?id=600919 Mozilla Firefox Bug 600919 - (WebP) Implement WebP image support >Dave Garrett 2012-12-29 11:54:16 PST > (In reply to patrck from comment #174) > Also Wikipedia/Wikimedia opened a bug and accepted it and I confirmed from > insiders that they are inplementing webp image support (This will be the > "Big Deal" ?). > > Adding the ability for WebP files to be used on Wikimedia doesn't > mean they'll be converting everything they already have to it. > If Wikipedia started dual-hosting all of their images in > both WebP and JPEG, that'd be a "Big Deal".
this could be done by using Google mod_pagespeed since it does on the fly WebP conversion. https://developers.google.com/speed/docs/mod_pagespeed/filter-image-optimize ModPagespeedEnableFilters convert_jpeg_to_webp Enabling convert_jpeg_to_webp causes the image optimizer to create webp images whenever it would otherwise create jpegs. The webp images are only served to modern browsers that support the format. Optimized jpeg images will continue to be served to older browsers.
Currently there is no support in MediaWiki for sending different thumbnails depending on the user-agent. I don't think this should be done within MediaWiki itself in any case, as it would fragment the parser cache. (In reply to comment #10) > this could be done by using Google mod_pagespeed since it does on the fly > WebP > conversion. > https://developers.google.com/speed/docs/mod_pagespeed/filter-image-optimize > Note that the Wikimedia image servers use nginx, rather than apache. We could, however, have a look at our 404-handler to provide this functionality. Anybody can remind me where that code resides?
Since the initial opening of this bug Google has significantly added to the webp software and added support for more metadata, transparency and a lossless coding. webp as of today would fit for shrinking both lossy jpeg and lossless png thumbnails in Wikipedia articles for those browsers supporting it. Mathias
Updating summary to note webp can serve for PNG needs as well.
Stats about ~30% bandwidth savings: http://blog.chromium.org/2013/02/using-webp-to-improve-speed.html
Per http://caniuse.com/#feat=webp browsers of 37.24% of people can handle WebP images right now (Chrome and Opera).
(In reply to comment #11) > Currently there is no support in MediaWiki for sending different thumbnails > depending on the user-agent. I don't think this should be done within > MediaWiki > itself in any case, as it would fragment the parser cache. > > (In reply to comment #10) > > this could be done by using Google mod_pagespeed since it does on the fly > > WebP > > conversion. > > https://developers.google.com/speed/docs/mod_pagespeed/filter-image-optimize > > > Note that the Wikimedia image servers use nginx, rather than apache. Well, there is also ngx_pagespeed, but assuming the conversion happens as a separate step, it's also easy to configure nginx [1] to serve the appropriate asset based on advertised Accept header. [1] http://www.igvita.com/2013/05/01/deploying-webp-via-accept-content-negotiation/
*** Bug 56832 has been marked as a duplicate of this bug. ***
