The one time that I've found a practical application for WebP was when a client needed to fit a roughly 1-megapixel photograph in less than 5 kbytes of storage space. JPEG starts falling off a cliff in terms of image quality once you push it to extreme compression factors (like down near quality-0), but WebP degrades very gracefully and relatively linearly.
The test images we put together turned into nearly unrecognizable blocky messes when compressed with JPEG, if they fit at all. The same test images, compressed with WebP, looked surprisingly decent and were quite usable.
That said, if our photo storage budget had been 10 kbytes instead of 5 kbytes, JPEG would have been fine for the project's purposes. It was that last little squeeze that really killed JPEG.
I remember a trick from the early web days of halving the resolution of a JPEG and then expanding the compressed result back to the original size. It'll be blocky, but much less blocky than just reducing the JPEG compression level for the same fize size reduction at the low end.
I believe WebM does (or at least the format can do) this automatically in low bitrate situations, without the external user needing to understand what's happening on the encode or decode end. I don't know if WebP inherits this trick and that explains it's low bitrate performance or if it's just better in other ways.
I find that Jeff Muizelaar's argument (not Arstechnica but what they talked about) very weak. He said WebP is not good because:
* Jpeg has some fancy features not seen in WebP (4:4:4 YCrCb, CMYK support, etc)
* Jpeg's compression is "good enough", and nobody cares about diskspace (cited Facebook 85%, Flickr 96% quality level)
* If WebP, why not Jpeg XR?
* WebP has no alpha channel support!
* There are "low hanging fruit" in Jpeg optimization such as progressive encoding.
Each of these points in isolation may be valid, but together they give me the feeling that he was arguing surgically. He said Jpeg is already very good, Jpeg is actually bad but there are low hanging fruit to improve it, and whether Jpeg is good or bad doesn't matter because nobody cares.
Personally I feel the "75% is already very good" argument to be the weakness. Facebook pictures are very poor compared to the original, and if diskspace is not a problem they would have increased it to 96% like Flickr.
I hope Mozilla supports the format and let the users decide.
One possible reason to push for improvements before accepting the new format into Firefox is suggested by Justin Lebar in a comment on http://bugzil.la/600919:
"In general, Mozilla should use its weight to improve the web in the long term, even if doing so is unpopular in the short term. In this case, by not accepting WebP in its current form, we're putting pressure on its developers to improve it in the ways that we think are important. Once we accept the codec, we lose this leverage. [...] Remember that even if we landed this patch tomorrow, it would still likely be years before this format saw wide adoption. The argument is that it's better to wait and throw our weight behind something we think moves the web forward, if and when that arrives."
Google has yet to demonstrate that WebP produces better image quality at the same or smaller file size than what's possible with JPEG. Until Google can kill it on that test, nothing else really matters because the format has no features above and beyond JPEG and none on the roadmap. That means all WebP has going for it is the quality size argument and that's yet to be proved.
Google has shown a lot of images that are smaller file sizes and look clearly worse to even the untrained eye. Show me same quality at a smaller size or better quality at the same size and then WebP can claim it's got something going for it. That hasn't happened yet so it's a negative when stacked up against JPEG and most of the current JPEG alternatives.
I'd like to respond to your criticism of my argument but I'm having trouble understanding it.
As for my point about Facebook, I believe that they do care about the size of the images. However, the fact that they can be trivially and losslessly reduced in size suggests they just don't care enough to invest in optimizing them. Presumably, they have more important things to be working on. This suggests that they might also have more important things to work on than switching to webp.
My apology for not being clear. The five points are summary of what you said and I hope there is no confusion.
Right after the five points, I object to your "surgical arguments" which is along the line of "Jpeg is not too bad, and even if it is bad, there are ways to fix them". The truth is that Jpeg is actually a very poor format. Image artifact is very poor at low quality, and compression is very poor at high quality. While I don't know for sure whether WebP is really that much better at high quality (my limited experience showed that it is), I disagree with your arguments that there is "nothing wrong or unfixable about Jpeg". Our eyes are accustomed to poor web Jpeg quality but I think if something better comes along people will see it.
Also, given Opera and Chrome already support WebP, if Mozilla throws its weight behind it, I think Safari and IE will oblige in short order. The browser landscape is very different from the days of early PNG, and adoption will be quick. Just look at how quickly Microsoft transforms into the "#1" advocate of HTML5.
My position isn't that there's "nothing wrong or unfixable about Jpeg" at all. There's lots wrong and fixable with JPEG. My problem with WebP is that it currently doesn't fix enough of the problems that JPEG has and that if we adopt it right now we might end up with another format that still has problems and will have to replace WebP with yet another format that fixes those problems later. JPEG took 6 years to standardize and has lasted for nearly 20, this suggests that we might not want to rush to commit to a 8 month old image format with a bitstream that was frozen the moment it became public.
As for support in other browsers, WebM is supported by Opera, Chrome and Firefox, plus it solves problem of being a royalty-free modern video codec and neither Safari nor IE have obliged in short order. What do you think that WebP brings that will make adoption happen faster than WebM?
I think let's just agree that Jpeg has a lot of problems and we'd like to seek the best replacement. Obviously high-compression rate is important or else everything should migrate to PNG, but the current Jpeg tradeoff between quality and size is not just not very good. Also interestingly, there seems to be a very wide spectrum of Jpeg lib quality from decent to very bad, and I found out about that while experimenting with WebP.
WebP is different from WebM in that there are IP issues. I think WebP is more like SVG/Canvas in that vendors don't see any "hurt" in supporting them once there is enough momentum behind. Of course, your point about making sure that we don't want to support any half-baked image format. I think WebP is beyond half-baked, and an initial pledge of experimental support -- instead of an outright rejection which seems to be tone -- doesn't hurt.
I've yet to see a compelling argument for why I should want a browser with WebP support. Unless images start out lossless, and then are encoded into WebP directly, all I'll ever get out of WebP is smaller images that have more encoder artifacts - and I don't want that. I've got plenty of bandwidth; I'd rather download images in their original JPEG or PNG formats, especially if that means I can then open them up in any image editor or viewer on my computer, instead of having to install some special (and likely buggy) new WebP viewer/converter.
I think if WebP offered useful features JPEG doesn't, like alpha channel support or support for higher bit depths or useful new metadata, that'd at least justify it, and people would be creating new demos that showed off the technology. We saw this with the uptake of support for PNG after people started showing how PNG's support for alpha transparency made it possible to do interesting things that you couldn't with JPEG/GIF. WebP has no such compelling feature.
We don't have plenty of bandwidth with mobile applications. It's quite common for even basic sites to slow to a crawl on 3G. Even with LTE just around the corner, richer multimedia at higher resolutions will partially offset those gains.
Note that according to Nielsen's Law bandwidth growth rate, while sill exponential, is slower than Moore's Law (transistor count) and Kryder's Law (disk space), so we will be increasingly bandwidth limited as time continues [1]. For an example just look at SSD hard drives. To overcome bandwidth limitations the best SSDs now have whole ARM based computers in them to compress data on the fly, reorder operations on the fly, and run its own garbage collection programs just to save from going over the already very fast SATA bus which the latest drives fully saturate.
SATA is saturated because the increase in performance between platter disks and SSDs is a big discontinuity in what had been a relatively slow but steadily rising curve in the max sequential speed of a disk. Right now SATA is playing catchup, and has had two fairly major iterations in a much shorter cycle than what used to be the case. SATA 6gbps isn't saturated by even the Vertex 3.
Mobile bandwidth is a problem for completely different reasons - I wouldn't equate them.
"We don't have plenty of bandwidth with mobile applications."
Because mobile devices have screens with 300ppi it's not a bad idea to use GIF or PNG files with less than 64 colors (adaptive). When you use dither (patern) the results are quite good given the filesize.
Google is essentially comparing WebP to JPEG right now like you would compare PDF to plain-text. They have a proof of concept ("look, the text appears on the screen!") that has a smaller file size but lacks any actual features. My concern is that once they implement all the features required of a mature image format (alpha, color modes, etc), size will be on par with another existing format.
My concern is that I don't see a roadmap for the missing features and there are existing next-gen codecs that already perform better than JPEG and do have those features.
Google announced more features for WebP at Google I/O (including lossless and animation amongst others). I've not seen any Mozillan response to that as yet.
"Google said they'd give everyone ponies! Respond!!!"
Please point me to the roadmap document for WebP that shows which features Google intends to implement and the schedules (even rough guesses) for getting those features implemented. Without that, I don't see what there is to respond to.
This mailing list post (and the Google IO video linked within it) is probably the closest thing to a roadmap that exists, though it's vague on timelines:
I personally am relatively comfortable with Google's throw it at the wall and see what sticks approach. I understand that others aren't but hope that Mozilla engages constructively so that WebP improves in a measurable way even if you/they have no intention of adopting it.
The "we need it to sit in ISO committees for 10 years before we can even think about implementing it" approach reminds me too much of the bureaucratic process trolling that Microsoft are so good at. It's good trolling because it's also a natural response and vaguely professional sounding, while still probably being either non-productive or actively detrimental to the technical outcome.
Note that from my amateur readings (notably http://sites.google.com/site/dlimagecomp/ms-ssim-results) JPEG-XR seems to be suffering from the exact problems that WebP is alleged to have (i.e. being designed for PSNR to the point that it's actually worse than venerable JPEG in SSIM and subjective tests). JPEG-2000 seems to have the same issue to a lesser degree. If Mozilla can bring some automated metrics to bear on this (and any parallel JPEG improvements), and metrics seems to be one of your/their strengths, then I'd be very happy, since it seems the JPEG-XR and 2000 teams may have been misled by their own metrics. Having multiple eyes on the problem, particularly those looking to find fault from the outside, would be great regardless of whether the result is WebP being improved or scrapped.
WebP should implement alpha transparency. That was in their promise but they never did it. That'd make it a jpeg-killer for me. A lossy image format that supports alpha transparency would be so great.
Striving for a lower file size is inherently a good thing, but as disk space is becoming cheaper and cheaper and it's not as important anymore. Judging from the comparison gallery at http://code.google.com/speed/webp/gallery.html, it's not very impressing. The result is much more blocky and there is significant loss in detail in detail-concentrated areas.
Case in point: the first image of a landscape has two major noticeable artifacts: the shadow of the mountain (mid-right) reveals the blocky compression of WebP. Second, the compression algorithm tends to smooth out a lot of detail. Observe how the vegetation gets mushed out. The clouds as well (mostly on the top left).
Great for video, not so much for images (from the gallery above anyway). I would like to see a better comparison with WebP vs JPEG but compressed to about the same file size and with a RAW source (to remove any compression bias).
You mention that it has better compression, which Microsoft certainly claims for it, but can you find any comparison that shows XR as better than standard JPEG when measured with SSIM rather than PSNR? Or subjective human tests[1]? There's quite a few showing it losing to JPEG. Surely they can't all have messed up their testing methodology, though creating and standardising a purpose built photo codec in 2009 that's worse in quality at many common rates than JPEG seems somewhat unbelievable too.
1: "the visual performance of HDPhoto showed notable
deficits, both in subjective and objective tests."
from Visual Quality Improvement Techniques of HDPhoto/JPEG-XR by T Richter
The test images we put together turned into nearly unrecognizable blocky messes when compressed with JPEG, if they fit at all. The same test images, compressed with WebP, looked surprisingly decent and were quite usable.
That said, if our photo storage budget had been 10 kbytes instead of 5 kbytes, JPEG would have been fine for the project's purposes. It was that last little squeeze that really killed JPEG.