4 ms·

WebP – faster decoding and rolls out across Google properties

35 points by rayshan 13y ago

dudus 13y ago
These are impressive numbers. Are there technical reason why IE or Firefox haven't adopted it yet? Or just political ones? http://caniuse.com/webp http://caniuse.com/webp
- gecko 13y ago
  Mozilla evaluated WebP in October and found its improvements dubious compared to alternatives: http://people.mozilla.org/~josh/lossy_compressed_image_study_october_2013/ http://people.mozilla.org/~josh/lossy_compressed_image_study... That said, they explicitly did not rule out including WebP in the future. They just concluded it wasn't yet ready. It looks like it may be getting closer to being ready.
- rayshan 13y ago
  I'm guessing purely political. See "Consensus & Standardization" for WebP: http://www.chromestatus.com/features/6471725441089536 http://www.chromestatus.com/features/6471725441089536 Similar story for Dart: http://www.chromestatus.com/features/6682831673622528 http://www.chromestatus.com/features/6682831673622528
  - d0ugie 13y ago
    Is there anything you can think of that Mozilla has to gain by not adopting WebP? I'm at a loss.
    - rayshan 13y ago
      My comment isn't directed at Mozilla, but other vendors as well. IMO you loose influence by adopting lots of other vendors' tech, whether it's WebP, Dart or asm.js, even if it is open. I'm curious what the tech community thinks of innovation at Opera now that they adopted webkit/blink. Perception is important.
      - azakai 13y ago
        > IMO you loose influence by adopting lots of other vendors' tech That shouldn't be how it works, and I don't think that's how it works. Good tech is adopted by other browsers all the time, just look at WebGL, WebRTC, Web Audio, and this isn't only recent but goes back to XMLHttpRequest and before. There are lots of specific issues and questions regarding every new technology. Those things matter, not a general "we lose if we adopt a tech another vendor proposed" approach, which you assume here.
        rayshan 13y ago
        I agree. I hope I'm wrong and I certainly hope the best tech win in the long run. Now looking at history of WebRTC, which was also initially drafted by Google, I have hope.
    - bsdetector 13y ago
      They won't need webp in their codebase 5 years from now when everybody is using h.265 (much better than webp) except a couple old sites. Browsers can add anything they want at any time, but they can't remove things without breaking part of the internet. If you just throw in anything that is marginally better then you just accumulate cruft. Google's attitude is, if it's 1% better then do it. Do any marginal improvement regardless of how much complication it adds. But sometimes you need the wisdom to say this 1% isn't worth it in the long run.
    - acdha 13y ago
      Huge win: lower security exposure. Image codecs are complex and a perennial source of exploitable bugs. There's also the cost of optimizing and testing code. I hope WebP has been improving because in the past it was very slow – as bad as JPEG-2000 – and it takes non-trivial effort to change that. Again, not a burden you'd jump to take on without some very clear wins. The case will become much stronger if the next generation codec delivers more of a win on file size.
- rakoo 13y ago
  Pointers to Mozilla decisions: https://bugzilla.mozilla.org/show_bug.cgi?id=600919 https://bugzilla.mozilla.org/show_bug.cgi?id=600919 http://muizelaar.blogspot.fr/2011/04/webp.html http://muizelaar.blogspot.fr/2011/04/webp.html TL;DR: webp wasn't better-than-jpeg enough at the time it was considered, with even some rejection off the published Google studies. I feel like they thought it was still too experimental (although I haven't followed the process so I may be wrong).
  - joshmoz 13y ago
    The Mozilla WebP bugs are a mess due to loads of poor comments. Read at your own risk. The bug you cite has been superseded by a new bug with the same poor quality of comments. I recently posted a more detailed summary of my own views on the second bug: https://bugzilla.mozilla.org/show_bug.cgi?id=856375#c174 https://bugzilla.mozilla.org/show_bug.cgi?id=856375#c174
    - cpeterso 13y ago
      I look forward to your update image study with Mozilla's mozjpeg and Google's latest WebP! I would guess that mozjpeg's results would not be much better than the JPEG results in your original study because you used jpgcrush.
    - skal65535 13y ago
      Since the bug is closed and we can no longer reply, i'll drop brief comments here: 1) We lack data showing that WebP is significantly enough better than JPEG in terms of compression. [...] If we omit Google numbers (that this blog post and the ones before reported), Facebook reported 20% saving as a starting point for mobile (http://internet.org/efficiencypaper http://internet.org/efficiencypaper). the Mozilla bug has good number reported (Netflix, Akamai and other CDNs, etc...) inbetween the noise. 2) Last time I checked, it was not possible to create large WebP images. I couldn't encode a ~20 megapixel image. This was fixed in libwebp0.4.0. (but i hope no web site is going to send me a 20megapixel image while i'm on my phone) 3) I suspect it's unlikely that MS will agree to include WebP support in IE, maybe ever. Not having MS on board, given their market share, is problematic. It means lots more header/UA checks and double solutions for every use of WebP, possibly for a long time. UA detection are here to stay for quite some time anyway, before all current browser versions are retired (if that ever happens). Responsive web put the load on server logic, then. 4) I haven't done extensive testing on this yet, but word is that WebP compression advantages fall off when an image gets larger than about 500x500 pixels. This might be why we see WebP perform a bit worse on the Tecnick image set (~1200x1200) than the Kodak set (~768x512) in my last study. This may also be impacting other peoples' tests. I'm curious to know more about this. VP8 uses 4x4 transform, not 8x8. That's the main difference with jpeg that limit the efficiency at high dimensions. Although 500x500 seems a bit low. Let's also note that your study was also using a downsampling version of the SSIM metric, which could be interacting favorably with jpeg's larger transform block. 5) Users can't do much with WebP images today if they save them. As Facebook learned, this frustrates users. As this is a bit of a chicken-and-egg problem it's less important, but it is a consideration. That was mostly an app problem. Android faces the same problem with the data proxy mentioned in the blog, but this is taken care of client-side. skal
lnanek2 13y ago
> The latest Chrome browsers for Android and iOS can significantly reduce cellular data usage by using proxy servers hosted at Google to optimize website content Ah, I was wondering why Chrome on my Android was so broken lately. I checked "Request desktop" like usual and refreshed and just couldn't get a broken page to give me the working desktop version at all. That always used to work. Eventually I had to switch to the Dolphin browser, change my user agent, uninstall Dolphin Jetpack which was similarly broken, and finally I got the working desktop version of the page...
- mdwrigh2 13y ago
  None of your response indicates that the proxy is the issue here.
hendry 13y ago
If you have the bright idea of converting your JPEG images with precious EXIF metadata, beware you might not be able to get it back out. https://code.google.com/p/webp/issues/detail?id=176 https://code.google.com/p/webp/issues/detail?id=176
ksec 13y ago
On another notes, doesn't the H.265 has a image spec as well. How is that getting on?

35 points by rayshan 13y ago

dudus 13y ago

These are impressive numbers. Are there technical reason why IE or Firefox haven't adopted it yet? Or just political ones? http://caniuse.com/webp http://caniuse.com/webp

gecko 13y ago
Mozilla evaluated WebP in October and found its improvements dubious compared to alternatives: http://people.mozilla.org/~josh/lossy_compressed_image_study_october_2013/ http://people.mozilla.org/~josh/lossy_compressed_image_study... That said, they explicitly did not rule out including WebP in the future. They just concluded it wasn't yet ready. It looks like it may be getting closer to being ready.
rayshan 13y ago
I'm guessing purely political. See "Consensus & Standardization" for WebP: http://www.chromestatus.com/features/6471725441089536 http://www.chromestatus.com/features/6471725441089536 Similar story for Dart: http://www.chromestatus.com/features/6682831673622528 http://www.chromestatus.com/features/6682831673622528
- d0ugie 13y ago
  Is there anything you can think of that Mozilla has to gain by not adopting WebP? I'm at a loss.
  - rayshan 13y ago
    My comment isn't directed at Mozilla, but other vendors as well. IMO you loose influence by adopting lots of other vendors' tech, whether it's WebP, Dart or asm.js, even if it is open. I'm curious what the tech community thinks of innovation at Opera now that they adopted webkit/blink. Perception is important.
    - azakai 13y ago
      > IMO you loose influence by adopting lots of other vendors' tech That shouldn't be how it works, and I don't think that's how it works. Good tech is adopted by other browsers all the time, just look at WebGL, WebRTC, Web Audio, and this isn't only recent but goes back to XMLHttpRequest and before. There are lots of specific issues and questions regarding every new technology. Those things matter, not a general "we lose if we adopt a tech another vendor proposed" approach, which you assume here.
      - rayshan 13y ago
        I agree. I hope I'm wrong and I certainly hope the best tech win in the long run. Now looking at history of WebRTC, which was also initially drafted by Google, I have hope.
  - bsdetector 13y ago
    They won't need webp in their codebase 5 years from now when everybody is using h.265 (much better than webp) except a couple old sites. Browsers can add anything they want at any time, but they can't remove things without breaking part of the internet. If you just throw in anything that is marginally better then you just accumulate cruft. Google's attitude is, if it's 1% better then do it. Do any marginal improvement regardless of how much complication it adds. But sometimes you need the wisdom to say this 1% isn't worth it in the long run.
  - acdha 13y ago
    Huge win: lower security exposure. Image codecs are complex and a perennial source of exploitable bugs. There's also the cost of optimizing and testing code. I hope WebP has been improving because in the past it was very slow – as bad as JPEG-2000 – and it takes non-trivial effort to change that. Again, not a burden you'd jump to take on without some very clear wins. The case will become much stronger if the next generation codec delivers more of a win on file size.
rakoo 13y ago
Pointers to Mozilla decisions: https://bugzilla.mozilla.org/show_bug.cgi?id=600919 https://bugzilla.mozilla.org/show_bug.cgi?id=600919 http://muizelaar.blogspot.fr/2011/04/webp.html http://muizelaar.blogspot.fr/2011/04/webp.html TL;DR: webp wasn't better-than-jpeg enough at the time it was considered, with even some rejection off the published Google studies. I feel like they thought it was still too experimental (although I haven't followed the process so I may be wrong).
- joshmoz 13y ago
  The Mozilla WebP bugs are a mess due to loads of poor comments. Read at your own risk. The bug you cite has been superseded by a new bug with the same poor quality of comments. I recently posted a more detailed summary of my own views on the second bug: https://bugzilla.mozilla.org/show_bug.cgi?id=856375#c174 https://bugzilla.mozilla.org/show_bug.cgi?id=856375#c174
  - cpeterso 13y ago
    I look forward to your update image study with Mozilla's mozjpeg and Google's latest WebP! I would guess that mozjpeg's results would not be much better than the JPEG results in your original study because you used jpgcrush.
  - skal65535 13y ago
    Since the bug is closed and we can no longer reply, i'll drop brief comments here: 1) We lack data showing that WebP is significantly enough better than JPEG in terms of compression. [...] If we omit Google numbers (that this blog post and the ones before reported), Facebook reported 20% saving as a starting point for mobile (http://internet.org/efficiencypaper http://internet.org/efficiencypaper). the Mozilla bug has good number reported (Netflix, Akamai and other CDNs, etc...) inbetween the noise. 2) Last time I checked, it was not possible to create large WebP images. I couldn't encode a ~20 megapixel image. This was fixed in libwebp0.4.0. (but i hope no web site is going to send me a 20megapixel image while i'm on my phone) 3) I suspect it's unlikely that MS will agree to include WebP support in IE, maybe ever. Not having MS on board, given their market share, is problematic. It means lots more header/UA checks and double solutions for every use of WebP, possibly for a long time. UA detection are here to stay for quite some time anyway, before all current browser versions are retired (if that ever happens). Responsive web put the load on server logic, then. 4) I haven't done extensive testing on this yet, but word is that WebP compression advantages fall off when an image gets larger than about 500x500 pixels. This might be why we see WebP perform a bit worse on the Tecnick image set (~1200x1200) than the Kodak set (~768x512) in my last study. This may also be impacting other peoples' tests. I'm curious to know more about this. VP8 uses 4x4 transform, not 8x8. That's the main difference with jpeg that limit the efficiency at high dimensions. Although 500x500 seems a bit low. Let's also note that your study was also using a downsampling version of the SSIM metric, which could be interacting favorably with jpeg's larger transform block. 5) Users can't do much with WebP images today if they save them. As Facebook learned, this frustrates users. As this is a bit of a chicken-and-egg problem it's less important, but it is a consideration. That was mostly an app problem. Android faces the same problem with the data proxy mentioned in the blog, but this is taken care of client-side. skal

lnanek2 13y ago

> The latest Chrome browsers for Android and iOS can significantly reduce cellular data usage by using proxy servers hosted at Google to optimize website content Ah, I was wondering why Chrome on my Android was so broken lately. I checked "Request desktop" like usual and refreshed and just couldn't get a broken page to give me the working desktop version at all. That always used to work. Eventually I had to switch to the Dolphin browser, change my user agent, uninstall Dolphin Jetpack which was similarly broken, and finally I got the working desktop version of the page...

mdwrigh2 13y ago
None of your response indicates that the proxy is the issue here.

hendry 13y ago

If you have the bright idea of converting your JPEG images with precious EXIF metadata, beware you might not be able to get it back out. https://code.google.com/p/webp/issues/detail?id=176 https://code.google.com/p/webp/issues/detail?id=176

ksec 13y ago

On another notes, doesn't the H.265 has a image spec as well. How is that getting on?