WebP – faster decoding and rolls out across Google properties

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.

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.

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.

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.

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