Why is Firefox still not supporting .webp? | Hacker News Reader

Why is Firefox still not supporting .webp?

reddit.com

65 pointskukx35 comments

My take: WebP is not a good format. It was a clever quick hack betting on the older generation of WebM taking over the world, and that hasn't happened.

- It doesn't compress well. It's twice the size of HEVC. We have similarly-performing VP10 now, but WebP is based on VP8, which is a 2006 codec that has lost to a 2003 codec in the market.

- It's actually 2 formats under one name. WebP has VP8 and its own lossless thing separately. JPEG-XR, JPEG 2000 and FLIF can use the same algorithm for both lossy and lossless.

- The lossy variant (which is the only interesting one) does not support full-resolution color. You have to live with chroma subsampling which messes up anything with sharp saturated colors.

- It's 8 bit only. This is too little for wide gamut displays which are becoming more common.

- It doesn't support progressive decoding at all (misses out on awesome HTTP/2 optimization that gives illusion of all images loading instantly).

- The alpha channel can only use lossless encoding. It's a big problem for non-binary transparency (complex shadows, smoke). That's the major usecase for it on the web, and that's the least efficient variant of WebP.

- It suffers from generation loss waaay more than any format.

http://flif.info/lossy.html

> The lossy variant (which is the only interesting one) does not support full-resolution color. You have to live with chroma subsampling which messes up anything with sharp saturated colors.

I always wondered if 4:4:4 but with more aggressive compression of chroma could beat the good old 4:2:0.

My two cents: Which version of webp should Firefox support? There are 3 major versions, and the subtleties in the 'extended' webp is only traceable through the releases of Chrome.

further, how can I tell which client supports which version of webp? `Accept: image/webp` is insufficient because it doesn't tell me which version or subset of features this client uses. Take for example, ios9b1 where webp was thought to have accidentally been available through CoreImage. It only supported WebP basic. But how would a server know this?

Lastly, webp is not setup to be successful for the next set of requirements: it is 8bit per channel color only (can't do 10bit needed for P3 or rec2020). It can't do full chroma subsampling (4:4:4). And the list goes on. It was a good first start, but it needs much more work before it can break out of the Google grip and get wide support.

"Which version of webp should Firefox support?": libwebp

Track the implementation here:

https://bugzilla.mozilla.org/show_bug.cgi?id=1294490

Build with '--with-system-webp':

https://bugzilla.mozilla.org/attachment.cgi?id=8808680&actio...

Still, it's not clear what subset of libwebp features will become popular. For example, I don't see much enthusiasm for animated webp. Even their own blog is full of GIFs: https://blog.google/products/allo/buzzfeed-stickers-google-a...

yes, but as the server responding to your webp enabled client, I can't tell which version of support you actually have. I can infer, but that's problematic.

That's an old, closed reddit post.

They have been actually actively implementing .webp support since August:

https://bugzilla.mozilla.org/show_bug.cgi?id=1294490

It's more about Google and Mozilla's differing approach to web standards, not the question posted in the title itself.

Great to see they're finally getting this in, since it results in real-world download reduction and quality improvement for users. Depends on content of course, but it's especially great for certain game content, icons, etc. I was never convinced their arguments against it outweighed the benefit of adding it, and was greatly disappointed when they opposed it. Hopefully Safari are still adding it. (Edit, seems Safari may not add it due to lack of 10-bit color support)

since it results in real-world download reduction and quality improvement for users

This is AFAIK really only true for images that can be lossy but which have an alpha channel, so a very specific use case.

The whole point of mozjpeg was to show that an improved JPEG encoder could achieve parity with WebP for all other use cases.

webp can do lossless with alpha channel, and the results (quality, size) are great. It also improves on jpeg, so it's actually a very general use case.

webp can do lossless with alpha channel

So can PNG. WebP doesn't add anything new here.

It also improves on jpeg

Debunked in the post you're replying to. The difference disappears when the JPEG encoder is updated (in a backwards compatible manner!) with modern encoding techniques the WebP encoder also uses, instead of ones dating back to 1998...

So can PNG. WebP doesn't add anything new here.

Webp compresses to much smaller file sizes than PNG in lossless mode.

Debunked in the post you're replying to

Sorry, which post?

AFAIK, Mozilla is very conservative in implementing non-standardized technologies. CSS styled scroll-bars anyone?

Please Mozilla never implement that!

Why? Every other browser supports it and hacking style with js is imho wrong

Scroll bar styling is a wrong feature and shouldn't be done by any method. The scroll bar is a part of the browser's UI and should look the same as the rest of the browser all the time, on every web page.

We already have that on Linux courtesy of Firefox switching to GTK3.

The top comment does a good job of explaining the reasoning. That said, since then more browsers (IIRC Safari) have announced that they are adding support, and the use case of lossy images with an alpha channel is important for games.

This has caused Mozilla to revisit the issue:https://bugzilla.mozilla.org/show_bug.cgi?id=1294490

WebP support was added briefly in the macOS Sierra (10.12) public betas, but was removed. It doesn't seem to work in Safari right now (macOS Sierra 10.12.2 beta), according to this test page:

https://developers.google.com/speed/webp/gallery

And it likely won't come back because of the lack of support for 10bit channels needed for P3 displays. Jpeg2000 (Apple's alternative to webp) does.

Jpeg2000 has nothing to do with Apple per say. It's an open standard managed by the Joint Photographic Experts Group (part of ISO). Not even sure if Apple even participates in the group.

WebP on the other hand is a proprietary format developed by a single company, an implementation of which is made available under an Open Source License.

Jpeg2000 is sort of an open standard, but OSS doesn't and can't use it because it's patent-encumbered.

"It has always been a strong goal of the JPEG committee that its standards should be implementable in their baseline form without payment of royalty and license fees... The up and coming JPEG 2000 standard has been prepared along these lines, and agreement reached with over 20 large organizations holding many patents in this area to allow use of their intellectual property in connection with the standard without payment of license fees or royalties." (Wikipedia)

So yes it's patent-encumbered but no more patent-encumbered than WebP.

https://chromium.googlesource.com/webm/libwebp/+/master/PATE...

That statement is AFAIK now absent from the JPEG site.

On the positive side, it's now old enough that some key patents (e.g. arithmetic coding) have actually expired.

If you're willing to deal with the development overhead of creating/storing multiple formats, which if you super care about optimized content serving you're doing anyway for sizes, then just use a picture element with fallback sources.

Progressive enhancement applies to more than just JS, and we've already been provided with a standard way to not have to care about browser support.

This is what the accept header is for. Browsers should implement whatever they feel is best for performance, security, maintainability, etc. Then the server should look at the accept header for a resource and serve a format the client can understand.

Imgix offers this as "Automatic Content Negotiation": https://docs.imgix.com/tutorials/improved-compression-auto-c...

Politics. There is a compile-time flag in firefox that allows it to use system codecs (for images as well as video). I ran a self-built Firefox for some time that had this enabled. Mainly to view media files on the local network, and because there was a time where people were putting up some files that chrome could open, but not firefox (I forgot what that format was - maybe it was even webp).

If you enable the flag (or, disable the built-in whitelist), then Firefox uses GStreamer (and I believe DirectShow on Windows or Quartz on macOS, but I'm not sure) to display the videos.

There also used to be the option of using MPlayer as a plugin, but NPAPI support was unfortunately removed.

Does Chrome support apng yet? Firefox does.

Is there a reason why a web browser could not integrate imagemagick (or equivalent) in order to support a "kitchen sink" set of formats?

Why not have Amiga IFF images on the web? ;)

One good reason is increased attack surface for security threats.

Have you seen the horrendous security issues with ImageMagick lately (last one to get a nice branding and logo was ImageTragick (https://imagetragick.com) )? Browsers have a hard enough time already dealing with the few formats they currently support.

Now either they manually add trusted support for all the additional formats (which would mean basically rewriting ImageMagick, but without the security issues, which is really hard considering the huge amount of file formats out there) or they rely on an external library and risk something like ImageTragick to cause global machine ownage of never before seen scale.

No. I like my browsers to be conservative there, though JPEG2000 would be cool to have :p

Amusingly, certain WWW browsers for the Amiga used DataTypes [0] to decode images so they would in theory support any format you like! Of course, the world was a much simpler place back then so I'd expect all sorts of security vulnerabilites to be present.

[0] a few DataTypes: http://www.monkeyhouse.eclipse.co.uk/amiga/boingbag/datatype...

You can use the <embed> tag to do that and it will largely work, or at least it used to.

Same reason it still hogs memory and crashes when I leave it open with no more than a dozen tabs for a while (Chrome never does this).

Reply on news.ycombinator.com