Opera embraces Google's open source JPEG killer
theregister.co.uk
theregister.co.uk
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.
Release note:
https://groups.google.com/a/webmproject.org/group/webp-discu...
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 cannot find any comparison, but that's because WEBP is a very bad name for searching on google: it gets shortened to 'web'.
http://code.google.com/speed/webp/
Which elsewhere claims that 99 human years are wasted due to uncompressed web content each day.
http://code.google.com/speed/articles/use-compression.html
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.
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.
This is the oldest entry a quick google returns, was he copying an earlier snowclone?
"Creative unveils potential iPod killer"
http://arstechnica.com/old/content/2002/10/1152.ars
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.
Google finds examples of Digital Research's GEM window environment being hailed as the Mac killer. This was back in 1985.
Searching for "IBM killer" finds references to the Digital VAX 9000, a failed minicomputer model that tried to beat IBM mainframes at their game.
Outselling implies that you are simply different. Killing implies that you have redefined the market by your awesomeness.
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.
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.
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.
http://code.google.com/speed/webp/ http://code.google.com/speed/webp/docs/riff_container.html