Steps to replicate the issue (include links if applicable):
What happens?:
a png thumb file is displayed
What should have happened instead?:
a webp thumb file is displayed
Software version (skip for WMF-hosted wikis like Wikipedia):
Other information (browser name/version, screenshots, etc.):
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | Feature | None | T338342 thumbimages of webp images should be in webp format instead of png | ||
| Open | None | T366422 The thumb_handler.php endpoint should be able to stream webp with the correct Content-Type header |
Hi @C.Suthorn, unfortunately this Wikimedia Phabricator task lacks some information.
If you have time and can still reproduce the situation: Please add a more complete description to this task. That should be
A good description should allow any other person to follow these steps (without having to interpret steps) and see the same results. Problems that others can reproduce can get fixed faster. Thanks.
This applies to all 29975 webp files at commons. Use mediasearch to choose any of them. On the file description page hover the mouse over the thumb download links and it will show a download url ending in ".webp.png" (and it is really silly to generate a png thumb from a png file. the webp will be smaller).
Please include such steps. So I have to go to https://commons.wikimedia.org/wiki/Special:MediaSearch?type=image to find something like https://commons.wikimedia.org/wiki/File:Johnrogershousemay2020.webp (the first one I tried had no thumb images). Please always include links in the future so other people save time - thanks.
I'd say this is not a bug as there is no code behaving wrongly. It's a feature request as code to handle this likely does not exist...
In my testing, webp previews are not visible at all in the uploader. It looks like webp needed to be added to the list of content types the javascript handles, I've made that change here: https://gerrit.wikimedia.org/r/c/mediawiki/core/+/928999/
This ticket lacks argumentation. There is no case provided for why a webp preview should be provided.
Even if there were argumentation, almost all our thumbnails are either png or jpg. Webp optimized thumbnails are conditionally used when performance benefits from it and your browser supports it. I see no reason why webp and only webp should use webp thumbnails and other thumbnails are not taking into consideration.
I'm going to boldly re-open this for further discussion
I was under the impression that we would dynamically send webp thumbnails when the accept: image/webp header was present, but that seems not to be the case, at least not with the files I tried
I think the argument goes:
We might also want to reconsider if we want the must render flag on. It made sense when this was first added, but now that so many browsers support webp, we maybe don't want that flag on so the original asset is used when appropriate (possibly would also be helpful for animation).
I don't think this is an urgent issue by any means, just that we might want to reconsider this now that webp support is essentially universal.
I was under the impression that we would dynamically send webp thumbnails when the accept: image/webp header was present
Only for the top x percent of most requested thumbnails (its a caching layer optimization)
Global webp browser support is currently 96%
Do we know if something like kiwix can handle webp thumbnails ?
So the argumentation is:
We imply:
Tested: whatsapp still doesn't support webp, and when you download a webp on iOS, it will auto convert it to jpeg.
Hmm, i was going by caniuse saying that IE11 was the newest browser that didn't support it, which based on wikitech-l is soon to be grade X. I think thumbs not working in a grade X browser would be reasonable, but you raise a good point about the broader ecosystem.
Maybe that leaves potentially using jpeg for thumbnails if it seems like the image would be well suited to it (lossy & no transparency). Not sure how viable it is to have the thumb format change based on image metadata.