Theoretically better compression than JPEG (but ... so was JPEG-2000).
Disadvantages:
The encoder actually loses to JPEG in many tests and almost everything it encodes looks like a blurry mess.
No support for any color format besides 4:2:0.
Almost no support in image editing applications.
An order of magnitude slower than JPEG.
Somehow I don't think this is much of a "JPEG killer". Its technology is 10 years out of date, entirely copy-pasted from H.264, and its featureset isn't even close to equalling JPEG's, let alone adding new features that people wanted.
When you say the encoder loses to JPEG and is blurry, are you talking about the new re-written encoder they released a month ago, or the old one that was just the WebM encoder?
Skal's new encoder on its slower modes does seem to do a good bit better. Its approach is quite slow compared to the regular VP8 encoder (which was already slow), though.
The code is actually rather interesting to read -- it basically uses K-means for a large portion of the encoding process, which is applicable in this case because of VP8's non-adaptive arithmetic coder. I've never seen an encoder done quite this way before.
I guess they'll use in their Turbo technology which is really great for mobile phones. Apart from North America and Europe, the rest of the world is still dealing with limited bandwidth caps and slow speed of GPRS/EDGE.
I never understand why JPEG XR (http://en.wikipedia.org/wiki/JPEG_XR) didn't take off. It seems that Microsoft really has some management problem to push things forward or they simply don't care that much about it after all.
Adding this way after the discssion in case it appears in future searches - the quotes don't really help with words that can be split into other words.
My great-grandfather's surname is Aland. I did some searching on him recently - a search for "Aland" also returns results for "Al and" and "a land", neither of which are relevant. Using the + prevents that.
Surely for images served over the web the key measurement is the speed gain due to smaller filesize minus the loss due to extra decompression time. It is after all a project hosted under Google's speed project.
Opera certainly seem to think they can compress and decompress the WebP image on-the-fly and still come out ahead speed-wise compared with the original (at a cost of quality) and their old JPEG system (with improved quality), at least over low-bandwith connections.
It might be a stupid question, but:
Is there an example of a hyped "whatever killer" that actually killed "whatever"? I have the feeling that all those Google, Facebook, Microsoft, iPad/iPad/iPhone killer that sensationalist journalists tend to write about are forgotten after half a year or so.
I'm sure somebody called Facebook a Myspace-killer at some point. But I'm not sure if facebook actually killed myspace, or if it is committing suicide.
When did all this whatever-Killer stuff start anyway? I'm not sure I've heard it in any other context than Apple's portable products e.g. iMac-killer, Wii-Killer, netbook-killer, Windows-killer, IE-killer, Ubuntu-killer, x86-killer or whatever don't seem to ring true to me even if they've dominated mindshare (in various markets, for various lengths of time). In general, why would you want to "kill" them, rather than say outsell them or offer better specs at a lower price? Seems very wierd and macho. Do any actual company representatives use this language, or is it just gadget blogs?
This is the oldest entry a quick google returns, was he copying an earlier snowclone?
To add further confusion, I wouldn't assume that a Register headline to be without snark, and similarly I've lately seen iPad-killer used as a sarcastic insult, with the implicit assumption that it will fail.
Sprint most definitely marketed the Instinct as an "iPhone killer", those were the words that appeared in the commercial. ARM chips are sometimes referred to as x86 killers.
Outselling implies that you are simply different. Killing implies that you have redefined the market by your awesomeness.
Too bad alpha channel support is not part of the WebP spec yet (although it's promised). That would have the potential to truly make it a JPEG killer.
Currently, PNG24 is the only (browser supported) image format that supports transparency, but the files can be huge.
The only advantage over JPEG currently is that the files are somewhat smaller for the same quality. Yes, that's nice, but not enough to displace an heavily ingrained format with 20 years of use.
It seems relevant that Opera is deploying it in order to support their "Turbo" mode, where smaller files is a much stronger positive, and interoperability means very little.
Interestingly, when Google first announced WebP, they used benchmarks to demonstrate its worth that suited the "Turbo" case perfectly. Everyone was confused why you'd test a format by re-compressing already lossy files. I'm assuming the other shoe will drop at some point and Google will start to transparently replace transient image files served by their services (e.g. Image Search or Picasas thumbnails, maybe even map tiles) as long as your browser supports WebP. Like Opera Turbo, mobile uses probably need this more than desktop in most of the world.
And of course they already ship the code for WebM, which probably helps somewhat. The two formats may very slightly re-inforce each other's use.
But that's hardly in the same league. The only use-case for PNG8 is small icons. For everything else, 8-bit paletted formats lead to banding and dithering like it's 1995.
Most of the large diagrams I make use fewer than 2^8 colors, but then I tend to use solid-color stuff rather than gradients. Granted, SVG is even better for those, but if they need to be rasterized (as they often do), PNG8 works fine.
I like to use slight gradients and/or antialiased text. Both use up palette entries like crazy.
Good point about SVG(.gz), I forgot about it. SVG it can do transparency as well, and is extremely compact, at least for diagrams. And even better, it allows to add interactivity to your diagrams.
WEBP would be as unsuited as JPEG for diagrams, as your high frequency drawing will be turned into a blurry mess. However, for things like layer effects and backgrounds, it'd still be nice to have a lossy raster format that supports partial transparency.
Theoretically better compression than JPEG (but ... so was JPEG-2000).
Disadvantages:
The encoder actually loses to JPEG in many tests and almost everything it encodes looks like a blurry mess.
No support for any color format besides 4:2:0.
Almost no support in image editing applications.
An order of magnitude slower than JPEG.
Somehow I don't think this is much of a "JPEG killer". Its technology is 10 years out of date, entirely copy-pasted from H.264, and its featureset isn't even close to equalling JPEG's, let alone adding new features that people wanted.