I think there's a reasonable expectation that a file on Commons be usable on Wikimedia wikis. If you allow WebP uploads and a user tries to reasonably insert the file into a page, it should convert it to PNG (similar to SVG) or some other format in the (likely) event that the user's browser does not support WebP. Similarly, I think there's a reasonable expectation that users be able to easily preview uploads of this nature (in the upload log, file description page, Special pages, etc.).

Until there's a converter in place or some sort of graceful fallback, I don't think WebP should be allowed.

mathias.schindler wrote:

MZMcBride: You are correct that this is a reasonable expectation and there are a number of files where direct browser support does not exist or is not fully available, including

DJVU http://commons.wikimedia.org/wiki/File:Alice_in_Wonderland.djvu
TIFF http://commons.wikimedia.org/w/index.php?title=File:South_African_President_Zuma.TIF&page=1
PDF http://commons.wikimedia.org/wiki/File:Gitmo-sop.pdf

If I understand the chronology correct, uploading of these files was permitted before fallback mechanisms existed to allow the kind of convenient embedding into other Wikimedia pages.

And yes, subsequent steps after allowing webp files were tools to display a jpeg preview for those browsers who do not understand webp.

The purposes of DjVu/TIFF and WebP are completely different: the former are used as multipage containers with book scans for Wikisource, while the latter is a format intended for general replacement for PNG due to its better compression. Therefore, uploading WebP files just to convert them to PNG due to lack of browser support makes no sense, PNG would serve just fine. Let's revisit this in a couple of years when browser support for this format will be more widespread (or it will fail and we wouldn't need to bother with it at all).

matthew.britton wrote:

(In reply to comment #3)

while the latter
is a format intended for general replacement for PNG due to its better
compression.

Just to avoid any confusion: WebP compression is lossy (it's based on a video codec) and is intended as a replacement for JPEG, not PNG.

We should probably do it for more than just commons (eg: as a default), re-gigging the component/product as such.

mathias.schindler wrote:

There is a patch for libgd with WebP support:

http://svn.php.net/viewvc?view=revision&revision=304041 (http://www.php.net/~pierre/gd_webp_take1.txt respectively)

Anyone know an example file for this btw ?

Adding basic upload support shouldn't be too hard and can't hurt. Embedding is something else, I don't think this should be enabled for a long while, and converting to png doesn't really sound like a good idea for the immediate future either.

Created attachment 7743
Example webp file

The image is from the JS lib weppy. http://github.com/antimatter15/weppy/blob/master/tinybrot.webp

Attached:

mathias.schindler wrote:

webp test file

This is a test image in the webp file format. The image is licensed as cc-by-sa. I am the creator of the image. A jpeg version for comparison can be found at http://commons.wikimedia.org/wiki/File:Netzregeln10-Volker-Beck.jpg

Attached:

Basic support to allow uploading of WebP is added in r75087

Short-term I'd recommend doing webp->jpeg conversion for inline viewing; it should be pretty straightforward to do.

Longer term, being able to produce optimized WebP thumbnails from JPEG sources as well could be advantageous (though this may require a magical future where caching issues with type negotiation are dealt with to deploy on Wikimedia!)

(In reply to comment #3)

Let's revisit this in a couple of years when browser support for this
format will be more widespread.

At least Safari, Firefox and IE do not support WebP natively. Still reopening this ticket to get rid of deprecated LATER resolution.

mathias.schindler wrote:

There are multiple workarounds for these browsers. The best option is to not serve webp files to these browsers but JPEG or PNGs instead. MediaWiki does the same when serving TeX files in various formats.

(In reply to comment #11)

Short-term I'd recommend doing webp->jpeg conversion for inline viewing; it
should be pretty straightforward to do.

Broke this out to bug 48519.

Longer term, being able to produce optimized WebP thumbnails from JPEG
sources
as well could be advantageous (though this may require a magical future where
caching issues with type negotiation are dealt with to deploy on Wikimedia!)

That's been broken out as bug 25611 some while ago.

(In reply to comment #13)

There are multiple workarounds for these browsers. The best option is to not
serve webp files to these browsers but JPEG or PNGs instead. MediaWiki does
the same when serving TeX files in various formats.

Chrome and Opera both advertise WebP support via their Accept headers. Combination of that + Vary: Accept should do the trick.

This should now be possible, by adding webp to the default accepted filetypes for upload. Still desirable for WMF deployment ?

Wikimedia Commons Village Pump sounds like a good place to ask the community whether anyone needs this.

In T27397#1406840, @TheDJ wrote:

This should now be possible, by adding webp to the default accepted filetypes for upload. Still desirable for WMF deployment ?

Yes. Is there any reason not to do this these days?

In T27397#1408367, @MZMcBride wrote:

Yes. Is there any reason not to do this these days?

Don't get me wrong, I really think WebP is a step in the right direction but let's not repeat history and step into the sandtrap that facebook left after enabling WebP.

Facebook story:
http://www.cnet.com/news/facebook-tries-googles-webp-image-format-users-squawk/

Just to clarify, this is about uploading WebP originals, and serving them as PNGs. So the problem for us here is mostly:.. what if people (try to) download the originals.

For the reverse; using WebP for thumbnails of PNGs and JPGs (like Facebook), we are talking about T27611.

If we would not enable, then I'm likely to explicitly disable for WMF, and enabled for all other MediaWiki installations.

In T27397#1408543, @TheDJ wrote:

Facebook story:
http://www.cnet.com/news/facebook-tries-googles-webp-image-format-users-squawk/

Just to clarify, this is about uploading WebP originals, and serving them as PNGs. So the problem for us here is mostly:.. what if people (try to) download the originals.

Either they open in Chrome or the same as if they download djvu and do not have the file extension or mime type associated with a program.

In T27397#1408543, @TheDJ wrote:

Facebook story:
http://www.cnet.com/news/facebook-tries-googles-webp-image-format-users-squawk/

Just to clarify, this is about uploading WebP originals, and serving them as PNGs.

PNG or JPG? This point still is not clear to me after re-reading this task.

If we would not enable, then I'm likely to explicitly disable for WMF, and enabled for all other MediaWiki installations.

We should focus this task on MediaWiki and do what's best for it, in my opinion. Though I don't see a reason that Wikimedia wikis would have reason to override MediaWiki's default behavior here. If Wikimedia wikis want to, I think we can address that in a separate future task.

In T27397#1408406, @McZusatz wrote:

In T27397#1408367, @MZMcBride wrote:

Yes. Is there any reason not to do this these days?

Don't get me wrong, I really think WebP is a step in the right direction but let's not repeat history and step into the sandtrap that facebook left after enabling WebP.

Sure. Thanks for bringing this up. It looks like it's been over two years since that Facebook incident and as @TheDJ notes, we're talking about different implementation approaches. This task is not about converting JPGs to WebP on upload as Facebook did, it's rather about essentially the opposite: accepting WebP uploads and converting them to JPG (or PNG?) when served as thumbnails.

I'd honestly be more concerned on Wikimedia Commons about a sand trap similar to the MP4 debacle, but my understanding is that WebP is an acceptably free format. If this is not the case, then now would be the time for people to speak up. That's what my question about reasons to not do this was getting at. We need to do a final check for blockers (security, performance, licensing) and then we should be good to go.

accepting WebP uploads and converting them to JPG (or PNG?) when served as thumbnails

and what happens to animated WebP "images"

Note: Let's rather split the discussion from this bug report. I quickly created https://commons.wikimedia.org/wiki/Commons:Village_pump#Allow_WebP_upload

In T27397#1408558, @Rillke wrote:

accepting WebP uploads and converting them to JPG (or PNG?) when served as thumbnails

and what happens to animated WebP "images"

https://gerrit.wikimedia.org/r/#/c/95872/ only mentions "renders WebP files as PNGs, because that handles transparency." so this is unclear and should be addressed first.

In T27397#1408552, @MZMcBride wrote:

In T27397#1408406, @McZusatz wrote:

In T27397#1408367, @MZMcBride wrote:

Yes. Is there any reason not to do this these days?

Don't get me wrong, I really think WebP is a step in the right direction but let's not repeat history and step into the sandtrap that facebook left after enabling WebP.

Sure. Thanks for bringing this up. It looks like it's been over two years since that Facebook incident and as @TheDJ notes, we're talking about different implementation approaches. This task is not about converting JPGs to WebP on upload as Facebook did, it's rather about essentially the opposite: accepting WebP uploads and converting them to JPG (or PNG?) when served as thumbnails.

But what happens if a user downloads the full version? In confusion, they will try to replace the .webp with .jpg and wonder why MS paint can't open the file. Then they download the thumbnail and spend some time on modifications and wonder why they can't upload as a new version... (see my post @ https://commons.wikimedia.org/wiki/Commons:Village_pump#Allow_WebP_upload )

In T27397#1408680, @McZusatz wrote:

But what happens if a user downloads the full version? In confusion, they will try to replace the .webp with .jpg and wonder why MS paint can't open the file.

A guided download or a file format guide shown just in time, when the user downloads might be helpful for other formats like SVG and djvu as well.

Change 221731 had a related patch set uploaded (by TheDJ):
Disable webp for now, so we can enable outside of WMF

https://gerrit.wikimedia.org/r/221731

Change 221737 had a related patch set uploaded (by TheDJ):
[WIP] Enable WebP uploads by default

https://gerrit.wikimedia.org/r/221737

I'm so glad that we are so accommodating to my stockers. Lol

Change 221731 merged by jenkins-bot:
Disable webp for now, so we can enable outside of WMF

https://gerrit.wikimedia.org/r/221731

Change 221737 merged by jenkins-bot:
Enable WebP uploads by default

https://gerrit.wikimedia.org/r/221737

Change 281973 had a related patch set uploaded (by Matanya):
webp: enabled by default - remove old dead code

https://gerrit.wikimedia.org/r/281973

Change 281973 merged by jenkins-bot:
webp: enabled by default - remove old dead code

https://gerrit.wikimedia.org/r/281973

Worth announcing, I think.

It's enabled and upload is allowed (tested on mediawiki.org) but thumbnailing seems to fail: https://upload.wikimedia.org/wikipedia/mediawiki/thumb/0/0a/Cat-on-laptop.webp/896px-Cat-on-laptop.webp.png gives me " Error creating thumbnail: An unknown error occurred. "

Looks like in addition to ImageMagick, converting to/from WebP requires installing the 'webp' package (ImageMagick shells out to cwebp/dwebp programs)

Change 331820 had a related patch set uploaded (by Brion VIBBER):
Add 'webp' package to ImageMagick role

https://gerrit.wikimedia.org/r/331820

The "old upload form" at https://commons.wikimedia.org/wiki/Commons:Upload does not allow .webp uploads yet. Using Special:UploadWizard works.

In T27397#2937266, @ToBeFree wrote:

The "old upload form" at https://commons.wikimedia.org/wiki/Commons:Upload does not allow .webp uploads yet. Using Special:UploadWizard works.

"Permitted file types: tiff, tif, png, gif, jpg, jpeg, webp, xcf, mid, ogg, ogv, svg, djvu, oga, flac, opus, wav, webm."

that includes "webp", so you should be able to upload a .webp file. If it doesn't work for upload, please give specific information such as a sample file and what browser you're using.

Note that it won't *thumbnail* yet until the fixes to puppet configuration are merged and run.

Oh!
I tried about 24 hours ago and it didn't seem to work from my smartphone, so I tried again, this time using the UploadWizard, and it worked. Having a look at Commons:Upload again, I must have overlooked "webp" in the list and thought I had found a still existing problem. It works now, thanks!

@ToBeFree great, good to know that's working for you. :D We're all busy at all-staff meeting today/tomorrow so the puppet updates to fix thumbnailing may or may not get out immediately, you should see an update on this bug when it's merged. :)

Change 331820 merged by Giuseppe Lavagetto:
Add 'webp' package to ImageMagick role

https://gerrit.wikimedia.org/r/331820

Yay.

I've created Category:WebP file format and Category:WebP files to track WebP (and WebP-related) files. I think I've collected all of them at the time of writing.

Do any programs natively output in WebP or are they just re-compressed JPEGs? If the latter, I would nominate blocking them on Commons.

In T27397#2965256, @Dispenser wrote:

Do any programs natively output in WebP

If there are none now, there will be anyways.

or are they just re-compressed JPEGs?

Being a different codec could also mean JPEGs could be re-compressed WebPs ;)

If the latter, I would nominate blocking them on Commons.

For what reason?