Overall the reception to WebP that I've seen so far has been pretty negative. Jason Garrett-Glaser wrote a popular review, but there have been similar response from others like Charles Bloom. Since these reviews, the WebP encoder has improved on the example used by Jason (old vs. new) but it's still not a lot better than a decent JPEG encoding. I also have a couple of thoughts on the format that I'd like to share.
Google claims it's better than JPEG but this study has some problems and as a result, isn't very convincing (Update: Google has a new study that's better). First, they recompress existing JPEG's. This is unconventional. Perhaps recompressing JPEG's is their target market, but I find that a little weird and it should at least be explained in the study. Second, they use PSNR as a comparison metric. This is even more confusing. PSNR has, for a while now, been accepted as a poor measure of visual quality and I can't understand why Google continues to use it. I think it would help the format's credibility if Google did a study that used uncompressed source images, SSIM as a metric and provided enough information about the methodology so that others could reproduce their results.
WebP also comes across as half-baked. Currently, it only supports a subset of the features that JPEG has. It lacks support for any color representation other than 4:2:0 YCrCb. JPEG supports 4:4:4 as well as other color representations like CMYK. WebP also seems to lack support for EXIF data and ICC color profiles, both of which have be come quite important for photography. Further, it has yet to include any features missing from JPEG like alpha channel support. These features can still be added, but the longer they remain unspecified, the more difficult it will be to adopt.
JPEG XR provides a good example of what features you'd want from a replacement for JPEG. It has support for an alpha channel and HDR among others. Microsoft has also put in the effort to have it formally standardized. However, it too is not without problems. The compression improvements it claims haven't matched evaluations other parties have done. I don't know enough about JPEG XR to say whether this is because the encoders are bad or because the format is not really that great.
Every image format that becomes “part of the Web platform” exacts a cost for all time: all clients have to support that format forever, and there's also a cost for authors having to choose which format is best for them. This cost is no less for WebP than any other format because progressive decoding requires using a separate library instead of reusing the existing WebM decoder. This gives additional security risk but also eliminates much of the benefit of having bitstream compatibility with WebM. It makes me wonder, why not just change the bitstream so that it's more suitable for a still image codec? Given every format has a cost, if we're going to have a new image format for the Web we really need to make it the best we can make it with today's (royalty-free) technology.
Where does that leave us? WebP gives a subset of JPEG's functionality with more modern compression techniques and no additional IP risk to those already shipping WebM. I'm really not sure it's worth adding a new image format for that. Even if WebP was a clear winner in compression, large image hosts don't seem to care that much about image size. Flickr compresses their images at libjpeg quality of 96 and Facebook at 85: both quite a bit higher than the recommended 75 for “very good quality”. Neither of them optimize the huffman tables, which gives a lossless 4–7% improvement in size. Further, switching to progressive JPEG gives an even larger improvement of 8–20%.
History has shown that adoption of image formats on the internet is slow. JPEG 2000 has mostly failed on the internet. PNG took a very long time, despite having large advantages. I expect that adoption may even be slower now than it was in the past, because there is no driving force. I would also be surprised if Microsoft adopted WebP because of their stance on WebM and their involvment in JPEG XR. Can WebP succeed without being adopted by all of the major web browsers? It's hard to say, but it wouldn't be easy. Personally, I'd rather the effort being spent on WebP be spent on a improved JPEG encoder or even an improved JPEG XR encoder.
Is JPEG still great? No. Is there a great replacement for it? It doesn't feel like we're there yet.
30 comments:
Hi,
both the blog-posts you quote are 1-year old.
A new encoder has been released with version 0.1.2. See for instance here: http://code.google.com/speed/webp/gallery.html
Also: you seem to mix photographic use-case (HDR) with image-on-the-web one (alpha channel).
Alpha channel is being experimented with, as well as yuv444 and metadata like ICC, EXIF, etc.
But the priority was to first release a better-tuned encoder.
about vp8 compatibility: changing the bitstream format is rather easy (and will be probably needed for alpha support) , but cuts WebP from hardware vp8 support. This something to consider carefully.
skal
(ps: what? parkjoy _again_ ? :))
> both the blog-posts you quote are 1-year old.
Rather 6 months old, right? Sep. 30 and Oct. 2 respectively.
> both the blog-posts you quote are 1-year old.
> A new encoder has been released with version
> 0.1.2. See for instance here:
> http://code.google.com/speed/webp/gallery.html
The new parkjoy images I linked to was encoded with the new encoder
>Also: you seem to mix photographic use-case
>(HDR) with image-on-the-web one
>(alpha channel).
HDR can be very useful for textures used with WebGL.
Hey Jeff,
In the hopes of being more concrete, how would you feel about adding WebP support in Firefox if it gained support for ICC profiles, an alpha channel, and other colorspaces? I'm trying to gauge whether "lacks features", "encoder not good enough", "waiting until other people use it" or "other" are the key blockers.
Peter:
Why don't you approach the PNG standards body to add another compression stream to the format?
The world doesn't need a new container format that is as terribly designed as WebP. Dare I say its not even a container, but a few byte header before raw data..
IMO, it's "lacks features", "waiting until other people use it" and "other": solution looking for a problem.
WebM is a much needed format, whereas WOFF and WebP are not. Please stop dividing the Web from the non-Web.
Google appear to have announced a fairly major revision of WebP at Google's IO conference. There's no text online yet that I can find, but it's in this presentation video:
http://youtu.be/30_AIEhar-I
WebP stuff starts about 20 minutes in and the new version details slide is at the 30 minute mark.
It apparently includes a long list of new features including lossless, alpha, metadata, animation, css-spriting support, tiling and 3D.
They also talk about a new SSIM based update to their previous image quality testing report.
At least the Chromium team thinks they are making good improvements to the format.
Photography? Firefox it not very photography friendly anyway.
For example, an issue about ICC v4 support has been floating around unresolved for more than 2 years:
https://bugzilla.mozilla.org/show_bug.cgi?id=488800
New study at:
http://code.google.com/speed/webp/docs/webp_study.html
addressing most comments about methodology.
skal
Microsoft isn't apposed to WebM support and pledged to support VP8 in IE9.
http://www.zdnet.com/blog/microsoft/microsoft-to-support-vp8-video-codec-with-internet-explorer-9-after-all/6264
Flickr and FB compress images higher than 75, sure, but do I have to point out they *are* compressing...? If they didn't care about size they wouldn't compress at all.
As for recompressing jpeg, that must be the idea Google has in mind. Sacrifice a little processing time to save bandwidth. Doesn't sound bad to me...
So basically, the situation now is this:
If I use Chrome, Picasa and other sites will be faster. If I use Firefox, they will be slower.
That's going to be 99% of what most users care about.
I could understand if the reason was that the format is proprietary, but since it's not, this seems like a disingenuous move.
I think this is something that users should vote on.
You may want to consider using it just to keep your users. Mozilla users will end up converting to other browsers because of no support.
Comments above argue that WebP now is totally different from WebP six months ago and any number of wanted features are totally being experimented with. Somehow I don't see how that helps the case that browsers should support WebP right now? What's so wrong with waiting to see if it settles into a decent and useful file format?
For many uses, your arguments don't matter. In fact, the examples of image sites you gave, especially facebook, could see a huge benefit from much smaller and (to the naked eye!) clearer images. As a photographer, I tend to be a purist, desiring image quality regardless of image size or clunk, but Facebook and a lot of other sites have needed a way to make much smaller without sacrificing their already shit quality. And on top of that, you might actually see these sites let you put up bigger, higher quality images, especially considering how little screen real estate is being used by the majority of people these days.
At the same time, rather than arguing against the format, wait until it's complete. Clearly, they are still putting work into it.
You make some good points, but for people who don't need to do anything but put a rectangular image up on a social networking site, this method could easily do what people require. There is nothing wrong with new standards when they are better. Are you that guy still standing up for copper too? Even though we know we are starting to push up against the wall of limitations? New isn't bad. If you can't even show a better alternative, or even comparable alternative, your entire post is pretty much moot.
Do you have any data to back up the claim that progressive JPEGs are 20% smaller?
AFAIK progressiveness (in and of itself) only makes JPEGs larger. Would love to be wrong though...
“If I use Chrome, Picasa and other sites will be faster. If I use Firefox, they will be slower.”
And that's why more and more are using Chrome instead of IE or Firefox.
http://marketshare.hitslink.com/browser-market-share.aspx?qprid=0
If it's a great technical improvement to jpeg by now is not important to users, but if they can save a few seconds or pay less for the bandwith, that is important.
Yoav Weiss:
The amount that progressive improves compression varies. This random image from http://farm2.static.flickr.com/1288/4672968856_2d80fdef5e_b.jpg
goes from 414045 bytes to 372861 by using progressive: http://people.mozilla.com/~jmuizelaar/progressive.jpg
@Jeff
Regarding the sample image, the sequential example contains ~20K of Profiles data that the progressive one does not. Other then that it does seem that progressive saves around 5% on that image.
I'd like to point out a study by Stoyan Stefanov (Then @Yahoo) http://www.yuiblog.com/blog/2008/12/05/imageopt-4/
This study shows a median 2.7% improvement resulting from use of progressive JPEGs on web images, and that larger image are more likely to be better compressed progressively, while smaller ones are better off as sequential JPEG.
All in all, while JPEGs can be better compressed by better encoders, progressive JPEG is not a silver bullet, and better encoders can also be used to improve WebP quality.
All in all, we need a better format, with modern compression techniques and with Alpha channel (to which the WebP team seem to be committed, even if it's currently not supported). While I agree that WebP is not feature complete and is still a work in progress, there's a big difference between saying "We may support it once it implements A,B,C" and saying "it lacks A,B,C so we don't support it".
Please reconsider.
EXIF is a terrible way to annotate digital assets. It should be killed and replaced with Flexible Extensible Digital Object Repository Architecture.
"Even if WebP was a clear winner in compression, large image hosts don't seem to care that much about image size."
Image hosts may not care, but users do care about download times, especially in low bandwidth situations.
You can apparently do some more black magic with progressive mode and mucking around with the huffman encoding to get another 5% size reduction with JPEG.
This seems somewhere between undocumented and witchcraft however:
http://doom10.org/index.php?topic=711.5
@Yoav
I definitely agree that we need a better image format. I just want to make sure that WebP is better at enough things to justify adding it to the web platform.
Google Chrome already has slightly better HTML5 support then Firefox. And statics already say Chrome is faster then Firefox (while I don't believe it, sometimes Firefox just feels faster then Chrome). If Firefox also is going to lack support for WebP. It really is going to use losers. I already twice chose Firefox above Chromium because sometimes Firefox *feels* faster. Plus it has a lot more addons then Chromium. If Chromium always felt faster then Firefox I might seriously leave Firefox and consider using Chromium!
And what' s wrong with supporting a image format which hasn't proven itself yet? WebP is open source and Google has the reputation to release good tools, api' s and documentation. It shouldn't be that much work to add WebP support. It wouldn't cost you years of precious time to add support.
Looks like Google has addressed a lot of the format's missing features now (http://googlecode.blogspot.com/2011/11/lossless-and-transparency-encoding-in.html). I'd be interested in seeing what your thoughts are now that transparency, ICC profiles, XMP metadata have all been added to the format.
Hey Jeff, after http://blog.chromium.org/2011/11/lossless-and-transparency-encoding-in.html announcing that WebP has gained support for ICC, animation, and alpha transparency in both lossless and lossy modes, I'd love for you to write a new blog post with your opinions on the state of the format, whether you think it's more compelling, and what comments if any Mozilla has on the progress so far.
Well, the format changed a lot and now supports a lot of the features that where missing.. ( http://code.google.com/speed/webp/ ). Would be nice if firefox addopts this new format. I think there isn´t really that much extra work in supporting that special image format, because the api of the lib doesn´t really change.. So it´s just about updating the lib via a pull request once it´s used in firefox..
I think the "let´s stick our head into the sand like a turkey" approach doesn´t work here, because we now have a "chicken egg problem".. If big browsers don´t support webp, it will never get popular..
I agree that the format is now incredibly compelling:
1) It is open
2) It supports lossy transparency compression (and lossless)
3) Lossy or lossless, it features great compression/quality rates
4) It has a ton of useful features (transparency, XMP metadata, ICC profiles, animation, tiling, etc)
5) It is evolving at an amazing rate
JPEG has been around for 20 years, and web images have stagnated with the closed format. It's time to move on, and an open platform like WebP with great performance and features is something solid to build upon.
It's time to re-think JPEG for the web.
I have to agree with many of the commenters, now is the time to reconsider integrating webp to help improve the format by gaining critical mass.
Firefox is visibly starting to fall behind the curve and browser market share the way IE did, so for the sake of progress please re-evaluate the specification and your stance - at the very least post to the bug if you feel this way still.
As web developers, we just want to be able to use the best technology to make the best experience for users. I'd like to start using WebP in my sites, but can't because of lack of support in Firefox... too bad.
Post a Comment