Re:Why is Firefox still not supporting .webp?
by pornel on Wednesday November 23, 2016 @09:22AM
(#13022797)
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.
Re:Why is Firefox still not supporting .webp?
by maxst on Wednesday November 23, 2016 @12:28PM
(#13024123)
> 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.
Re:Why is Firefox still not supporting .webp?
by cflat on Wednesday November 23, 2016 @08:22AM
(#13022432)
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.
Re:Why is Firefox still not supporting .webp?
by cflat on Wednesday November 23, 2016 @11:38AM
(#13023749)
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.
Re:Why is Firefox still not supporting .webp?
by markdog12 on Wednesday November 23, 2016 @08:24AM
(#13022442)
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)
Re:Why is Firefox still not supporting .webp?
by markdog12 on Wednesday November 23, 2016 @10:53AM
(#13023418)
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.
Re:Why is Firefox still not supporting .webp?
by gcp on Wednesday November 23, 2016 @10:57AM
(#13023456)
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...
Re:Why is Firefox still not supporting .webp?
by gnu8 on Wednesday November 23, 2016 @11:51AM
(#13023845)
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.
Re:Why is Firefox still not supporting .webp?
by gcp on Wednesday November 23, 2016 @07:18AM
(#13022024)
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.
Re:Why is Firefox still not supporting .webp?
by aorth on Wednesday November 23, 2016 @07:29AM
(#13022108)
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:
Re:Why is Firefox still not supporting .webp?
by spiralpolitik on Wednesday November 23, 2016 @08:55AM
(#13022623)
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.
Re:Why is Firefox still not supporting .webp?
by spiralpolitik on Wednesday November 23, 2016 @09:59AM
(#13023055)
"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.
Re:Why is Firefox still not supporting .webp?
by larzang on Wednesday November 23, 2016 @07:31AM
(#13022123)
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.
Re:Why is Firefox still not supporting .webp?
by kogir on Wednesday November 23, 2016 @09:52AM
(#13023005)
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.
Re:Why is Firefox still not supporting .webp?
by captainmuon on Wednesday November 23, 2016 @10:16AM
(#13023163)
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.
Re:Why is Firefox still not supporting .webp?
by pilif on Wednesday November 23, 2016 @08:08AM
(#13022345)
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
Re:Why is Firefox still not supporting .webp?
by rosbrith on Wednesday November 23, 2016 @08:35AM
(#13022511)
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.
- 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
I always wondered if 4:4:4 but with more aggressive compression of chroma could beat the good old 4:2:0.
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.
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...
They have been actually actively implementing .webp support since August:
https://bugzilla.mozilla.org/show_bug.cgi?id=1294490
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.
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...
Webp compresses to much smaller file sizes than PNG in lossless mode.
Debunked in the post you're replying to
Sorry, which post?
This has caused Mozilla to revisit the issue:https://bugzilla.mozilla.org/show_bug.cgi?id=1294490
https://developers.google.com/speed/webp/gallery
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.
So yes it's patent-encumbered but no more patent-encumbered than WebP.
https://chromium.googlesource.com/webm/libwebp/+/master/PATE...
On the positive side, it's now old enough that some key patents (e.g. arithmetic coding) have actually expired.
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.
Imgix offers this as "Automatic Content Negotiation": https://docs.imgix.com/tutorials/improved-compression-auto-c...
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.
Why not have Amiga IFF images on the web? ;)
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
[0] a few DataTypes: http://www.monkeyhouse.eclipse.co.uk/amiga/boingbag/datatype...