The main take-home here is that while Google's numbers all show WebP as being objectively better, the metrics they chose for comparison were relatively bad (i.e., some of them didn't take into account colour or didn't model colour correctly), and once you accounted for that the numbers were not nearly as good a story for WebP; in some cases, JPEG outperformed it.
The facts that (1) WebP was not terribly compelling technically, (2) JPEG is already supported by everything on the web, not to mention devices and mobile phones etc, and (3) there's still headroom to improve JPEG in a backwards-compatible way, meant that WebP was (and, it seems, remains) a non-starter.
You can have icon files 3-4 times smaller, and large photorealistic images 2 times smaller than the regular PNG.
I assumed it would switch between the original and the compressed version. Instead it's swapping out the background to demonstrate transparency, which could probably be made more obvious.
Ok, it put them into one single zip and can't remember if it was solid or not, so it might be the cross-file compression that makes the major difference here.
BMP have formats which support 1-bit and 8-bit alpha channels http://en.wikipedia.org/wiki/BMP_file_format. Just open any file in Photoshop and save as BMP then click advanced. Not sure of browser support.
If you're seeing BMP+ZIP being smaller than PNG it only means your PNG encoder is poor. This can be easily fixed with a PNG optimizer like Zopfli, AdvPNG or OptiPNG.
...will do this automatically for you.
A multi-format, recursive, multiprocessor aware, command line image optimizer utility that uses external tools to do the optimizing.
For an all in one GUI for Mac approach to this, try ImageOptim
Now we'll have two similar but competing technologies and web developers will simply resort to the older formats.
As an exercise, try having your avatar only in the WebP format and see how useful it'll be.
That way you don't really care either way on the backend.
Suggests a 5x benefit over PNG for mobile app icons.
Comparing formats in a fair way is hard. "Looks almost the same" is a common fallacy — small change in quality can have dramatic change in file size, e.g. JPEG 80 and JPEG 90 look almost the same, but one is 2x larger than the other!
For example lossy WebP doesn't support full color resolution, but JPEG by default does. If you don't correct for that you're telling JPEG to save 4x as much color, and the difference is usually imperceptible, because that's the whole point of chroma subsampling.
When you compare with lossy WebP, then the right thing is to use lossy PNG as well.
I can make lossy PNG 4 times smaller than what you get from Photoshop (http://pngmini.com), so that'd make the comparison more fair, and the difference less dramatic.
Does anyone have further information on this?
Meanwhile, JPEG is free.
Gfycat seems to be getting more and more popular or at least I'm personally starting to see a lot more of their links in place of imgur gif links.
This is how the click to play in Firefox works, it's nice. One thing I haven't figured out how to do is trust embeds from a site (for example, Youtube and Vimeo both have well behaved embeds, so I'd like to whitelist them, but not many of the third party sites I see them on).
For example <img src=vid.mp4> could autoplay looped video without audio, just like GIF, except using tiny fraction of bandwidth and CPU (thanks to HW acceleration) than GIF.
I can't easily pick and choose which of these I want, which means that we end up with 20MB GIFs that could easily be 1/5 the size, and crazy hacks to get lossy images working with transparency.
This is particularly painful for HTML5 gaming in my previous experience. For one of my projects that involved a giant, high-res game board with transparency (Nick's online Pai Sho), I ended up manually slicing the board up, converting center pieces to JPEG and leaving the edges in PNG. The images are all pasted together to make the final, seamless experience. What a PITA!
4chan has, and it's significant not only because they have a lot of traffic, but also because their implementation has to be pretty solid -- 4chan users would love nothing more than to troll the administrators by breaking this.
Not really worth it. You'd post something once, then you'd get banned for a week. Unless you have a fleet of proxies or can keep changing ip address somehow, and can keep posting while they try to fix whatever exploit it is you found. Kind of hard to target admins when they're all anonymous, too.
It might be possible to do an APNG-style backwards-compatible animated JPEG, but it'll still be worse at it than video formats will be.
script animation is actually not supported when svg is used from an img tag. only declarative.
Where have you heard or read that it is on the chopping block?
evidence of actual standards activity and implementations from as recently as June 2014 show instead an active merging of css animation with svg animation into a single consistent model called "web animation" 
the implementation of this merging effort in chrome's blink rendering engine , and a rationalisation for this webanimation effort that promotes not a removal of the svg animation features (which are already implemented in everything but IE), but an expansion of their powers, being advocated by both google and mozilla 
Just because IE is lagging behind doesn't mean this feature is cut. Just because Ian Hickson says the feature is deprecated doesn't mean that it is, or that browser devs will follow whatever he says.
What it does mean though, is they are attempting to cut the feature's dependence on "SMIL", while retaining the currently implemented features. so I think that whatever works in browsers now, you can more or less rely on that working in future browsers as well. So yes, my suggestion is still useful and it's still awesome. And if you use css animations inside the svg (which totally works) instead of svg-smil animations, you can even get it working in IE10
I see many "big" webm videos on 4chan, much bigger than gifs. (in dimensions, not in bytes) and they are still smaller (in bytes) than the (dimensionally) smaller gifs.
Wouldn't it bring a huge traffic shrink, if every uploaded gif was converted to a, probably, tiny webm?
In mobile apps? Are they really animated GIFs?
We need a copy-pastable, mute by default <video> format to replace GIFs.
NVM I found what I was looking for:
People propose plenty of things with technically sound code, but there's far more to developing a platform than including everything that's technically sound. You have to make decisions as to what you wish to include. Once a something becomes near universal (in terms of marketshare, not in terms number of browsers; see IE's peak for the clear examples there!) it becomes treated as a baseline; once it's there it's incredibly hard to remove. Every time something else gets added that's more code to maintain, more code to ensure correctness (and security!) thereof, and a higher barrier of entry to the browser market. As a result, the default answer to adding anything should be "no".
Many things of interest developers might want to do currently require co-operation from the browser vendors, and their default position is 'no' unless it is in their commercial interest. Also, any one of the browser vendor vetoing the proposal is enough to kill it. Apple/Google/Microsoft are all huge companies with many products, so it's quite likely that you are a direct competitor to at least one product from one of the browser vendors, giving them extra incentive to veto most of the time.
Until the web is a platform where the vendors don't have the power to veto basic functionality like decoding an image it will remain the plaything of the browser vendors, used to bludgeon their competition.
Also our empiric measurments have shown, that WebP degrades more gracefully as you lower quality (compression artifacts aren't as visible) which allowed us to save about 30% of bandwith total by serving WebP to Androids and Chrome clients.
Reminds me of MNG, where we had an animation format with support for alpha and either PNG or JPEG style compression of frames, but it never got a pervasive browser implementation so it died. (I get the impression there were strong technical reasons for that, of course.)
Coincidentally, MNG also indirectly solved this problem. JNG was a subset-format of MNG that provided JPEG-compressed static images with optional support for alpha, so implementing MNG implied implementing JNG. But we never got it on the web.
At the very least, instead of just saying 'WebP is bad', they're putting their money where their mouth is and advancing the state-of-the-art in JPEG encoding so that people won't need WebP (other than the alpha channel use case, that is.)
Are there many websites using WebP that aren't Google properties?
I'll be interested to see if a VP9- or Daala-based version of WebP is more compelling.
Try gif2webp and gif2apng converters on this example, and you will know:
Is the test set of images available?
The test set of images is here:
If you're interested, https://github.com/dwbuiten/smallfry is program similar to JPEGMini that uses mozjpeg as its backend.
mozjpeg does Trellis quantization, there is no detailed explanation about jpegmini, a guess is it optimizes the DCT similarly to how it is described in this paper:
Mike Shaver had a good comment in the Mozilla feature-request ticket which is no doubt representative of many other projects' concerns:
None of this is insurmountable, of course, but it made a lot of people hesitant to invest heavily in it. I wrote about the long-term risks awhile ago:
The situation is getting better – OpenJPEG is now actively developed (see http://www.openjpeg.org), supports many of the more valuable features (e.g. tiled decoding so you can avoid decoding an entire large image to extract a fragment), and is becoming an official reference implementation:
Recently ImageMagick and Pillow (the maintained fork of the Python Imaging Library) added support for JPEG-2000 using OpenJPEG and the same trend seems to be happening in other places. The big remaining challenge is browser support for non-Apple browsers but that's now possible, if somewhat grotesque, using Emscripten on OpenJPEG to render into a canvas tag.
This also makes me question the use of metrics to measure image quality.
If your goal is to demonstrate 'JPEG can deliver better quality than this format by using 4:4:4, because that format can't do 4:4:4', then that's great, but it's a different observation than the one they're trying to make. (Also, I would be pretty curious about whether the different subsampling produces superior file sizes.)
The list of things that WebP offers that JPEG, PNG, or GIF alone will never address.
And the saying about gift horses' mouths applies to FB's horses too ;)