6 ms·

Why is Firefox still not supporting .webp?

65 points by kukx 10y ago

Grue3 10y ago
Does Chrome support apng yet? Firefox does.
cerved 10y ago
AFAIK, Mozilla is very conservative in implementing non-standardized technologies. CSS styled scroll-bars anyone?
- abrowne 10y ago
  Please Mozilla never implement that!
  - cerved 10y ago
    Why? Every other browser supports it and hacking style with js is imho wrong
    - gnu8 10y ago
      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.
- gbuk2013 10y ago
  We already have that on Linux courtesy of Firefox switching to GTK3.
gcp 10y ago
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 https://bugzilla.mozilla.org/show_bug.cgi?id=1294490
- aorth 10y ago
  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 https://developers.google.com/speed/webp/gallery
  - cflat 10y ago
    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.
    - spiralpolitik 10y ago
      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.
      - lmm 10y ago
        Jpeg2000 is sort of an open standard, but OSS doesn't and can't use it because it's patent-encumbered.
        spiralpolitik 10y ago
        "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/PATENTS https://chromium.googlesource.com/webm/libwebp/+/master/PATE...
fhoffa 10y ago
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 https://bugzilla.mozilla.org/show_bug.cgi?id=1294490
- Tarq0n 10y ago
  It's more about Google and Mozilla's differing approach to web standards, not the question posted in the title itself.
- markdog12 10y ago
  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)
  - gcp 10y ago
    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.
    - markdog12 10y ago
      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.
      - gcp 10y ago
        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...
larzang 10y ago
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.
LeoPanthera 10y ago
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? ;)
- herge 10y ago
  One good reason is increased attack surface for security threats.
- pilif 10y ago
  Have you seen the horrendous security issues with ImageMagick lately (last one to get a nice branding and logo was ImageTragick (https://imagetragick.com 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
- rosbrith 10y ago
  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/datatypes.htm http://www.monkeyhouse.eclipse.co.uk/amiga/boingbag/datatype...
- lmm 10y ago
  You can use the <embed> tag to do that and it will largely work, or at least it used to.
cflat 10y ago
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.
- fhoffa 10y ago
  "Which version of webp should Firefox support?": libwebp Track the implementation here: https://bugzilla.mozilla.org/show_bug.cgi?id=1294490 https://bugzilla.mozilla.org/show_bug.cgi?id=1294490 Build with '--with-system-webp': https://bugzilla.mozilla.org/attachment.cgi?id=8808680&action=edit https://bugzilla.mozilla.org/attachment.cgi?id=8808680&actio...
  - maxst 10y ago
    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-allo-give-you-one-more-reason-be-thankful/ https://blog.google/products/allo/buzzfeed-stickers-google-a...
  - cflat 10y ago
    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.
pornel 10y ago
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 http://flif.info/lossy.html
- maxst 10y ago
  > 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.
kogir 10y ago
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-content-negotiation https://docs.imgix.com/tutorials/improved-compression-auto-c...
captainmuon 10y ago
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.
pcglue 10y ago
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).

65 points by kukx 10y ago

Grue3 10y ago

Does Chrome support apng yet? Firefox does.

cerved 10y ago

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

abrowne 10y ago
Please Mozilla never implement that!
- cerved 10y ago
  Why? Every other browser supports it and hacking style with js is imho wrong
  - gnu8 10y ago
    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.
gbuk2013 10y ago
We already have that on Linux courtesy of Firefox switching to GTK3.

gcp 10y ago

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 https://bugzilla.mozilla.org/show_bug.cgi?id=1294490

aorth 10y ago
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 https://developers.google.com/speed/webp/gallery
- cflat 10y ago
  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.
  - spiralpolitik 10y ago
    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.
    - lmm 10y ago
      Jpeg2000 is sort of an open standard, but OSS doesn't and can't use it because it's patent-encumbered.
      - spiralpolitik 10y ago
        "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/PATENTS https://chromium.googlesource.com/webm/libwebp/+/master/PATE...

fhoffa 10y ago

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 https://bugzilla.mozilla.org/show_bug.cgi?id=1294490

Tarq0n 10y ago
It's more about Google and Mozilla's differing approach to web standards, not the question posted in the title itself.
markdog12 10y ago
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)
- gcp 10y ago
  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.
  - markdog12 10y ago
    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.
    - gcp 10y ago
      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...

larzang 10y ago

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.

LeoPanthera 10y ago

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? ;)

herge 10y ago
One good reason is increased attack surface for security threats.
pilif 10y ago
Have you seen the horrendous security issues with ImageMagick lately (last one to get a nice branding and logo was ImageTragick (https://imagetragick.com 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
rosbrith 10y ago
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/datatypes.htm http://www.monkeyhouse.eclipse.co.uk/amiga/boingbag/datatype...
lmm 10y ago
You can use the <embed> tag to do that and it will largely work, or at least it used to.

cflat 10y ago

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.

fhoffa 10y ago
"Which version of webp should Firefox support?": libwebp Track the implementation here: https://bugzilla.mozilla.org/show_bug.cgi?id=1294490 https://bugzilla.mozilla.org/show_bug.cgi?id=1294490 Build with '--with-system-webp': https://bugzilla.mozilla.org/attachment.cgi?id=8808680&action=edit https://bugzilla.mozilla.org/attachment.cgi?id=8808680&actio...
- maxst 10y ago
  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-allo-give-you-one-more-reason-be-thankful/ https://blog.google/products/allo/buzzfeed-stickers-google-a...
- cflat 10y ago
  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.

pornel 10y ago

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 http://flif.info/lossy.html

maxst 10y ago
> 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.

kogir 10y ago

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-content-negotiation https://docs.imgix.com/tutorials/improved-compression-auto-c...

captainmuon 10y ago

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.

pcglue 10y ago

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).