Weekly Edition
Return to the Announcements page
| |||||||||||||
WebP, a new image format for the Web (The Chromium Blog)
On its Chromium Blog, Google has announced a new image format called WebP. It is based on techniques from Google's recently open-sourced VP8 video codec and shows some significant size reductions for image data. There is also a gallery available to compare original and WebP-compressed images.
"While the benefits of a VP8 based image format were clear in theory, we needed to test them in the real world. In order to gauge the effectiveness of our efforts, we randomly picked about 1,000,000 images from the web (mostly JPEGs and some PNGs and GIFs) and re-encoded them to WebP without perceptibly compromising visual quality. This resulted in an average 39% reduction in file size. We expect that developers will achieve in practice even better file size reduction with WebP when starting from an uncompressed image."
(Thanks to Martin Jeppesen.)
(Log in to post comments)
WebP, a new image format for the Web (The Chromium Blog) Posted Sep 30, 2010 22:33 UTC (Thu) by gmaxwell (subscriber, #30048) [Link]
I wish them luck but I also wished they explained a bit better how this is superior to Jpeg2k, JPEG XR, and JPEG+arithmetic coding (patents expired a while back)... all of which do nicely better than JPEG.
Or how it compared simply more advanced JPEG encoders none of the widely used jpeg encoders use things like RDO optimization or activity masking, techniques which are used to great effect in the better video encoders.
Additionally, if the internet is to deploy something new (not the stuff that I just named) why should it be something technologically contemporary to about 2003/2004? There has been a lot of exciting image coding research and results since then, e.g. http://www.ponomarenko.info/adct.htm and https://sites.google.com/site/dlimagecomp/Home (plus a lot of other things which only exist as academic papers right now). VP8 even lacks some of the things that contemporary video codecs have which would be useful like adaptive quantization.
And one without an efficiently coded alpha channel and scalability to lossless? I find it really hard to believe that something will be widely adopted unless it satisfies a broad set of needs otherwise we're left with JPEG being "good enough and widely compatible"
With only 4:2:0 colorspace it means that if size is no object plain JPEG will still deliver better quality on many images.
It's also disappointing that the performance numbers are fairly vague "without perceptibly compromising visual quality" isn't defined. I could take a regular JPEG encoder and re-compress a great many files "without perceptibly compromising visual quality" and get some savings. Whats the additional improvement beyond that? How does JPEG+Arith, JP2K, and JPEG XR compare? ... They don't even get mentioned, for some reason. Much less the state of the art research codecs.
I'd be surprised if the improvement weren't _less_ from uncompressed originals the jpeg compressed files already have JPEG like nose, if your codec is reasonably good at recompressing block-DCT like noise then you'll do fairly well on already compressed inputs. Though we don't even know what the improvement really is because they didn't give numbers for the same recompression trick with plan jpeg.
It's interesting for sure and the web could certainly use a better format for continuous tone images. But it could also use lossless support, alpha channels, and there are already several more mature contenders that offer these things. As of right now it sounds to me like a somewhat myopic improvement which may only be attractive someone who already has a VP8 decoder, needs to squeeze down their bandwidth bills, doesn't care about all the other features lacking in JPEG, and controls both the server and the client.
Oh well at least it has metadata, unlike webm. ;)
WebP, a new image format for the Web (The Chromium Blog) Posted Oct 1, 2010 1:39 UTC (Fri) by gmaxwell (subscriber, #30048) [Link]
I should correct myself, the segment map in vp8 would be perfectly useful for adaptive quantization in still images.
WebP, a new image format for the Web (The Chromium Blog) Posted Oct 1, 2010 1:56 UTC (Fri) by shiar (subscriber, #67206) [Link] Their Comparative Study page does in fact contain a few more details, including methodology (apparently targetting PSNR), JP2k comparison and JPEG recompression. Regardless I'm hoping for some independent examination, particularly involving raw files.
WebP, a new image format for the Web (The Chromium Blog) Posted Oct 1, 2010 10:53 UTC (Fri) by marcH (guest, #57642) [Link]
> needs to squeeze down their bandwidth bills,
By the way if web designers (i.e., the people who actually get to choose images) had the tiniest interest in bandwidth bills then they would not consistently try to break the "back" button (and make it reload the previous page)
http://dev.opera.com/forums/topic/224464
WebP, a new image format for the Web (The Chromium Blog) Posted Oct 1, 2010 18:52 UTC (Fri) by cmccabe (guest, #60281) [Link]
> And one without an efficiently coded alpha channel and scalability to
> lossless? I find it really hard to believe that something will be widely > adopted unless it satisfies a broad set of needs otherwise we're left > with JPEG being "good enough and widely compatible"
Why does it need to be lossless? PNG already provides lossless, for the small number of people who want that.
> As of right now it sounds to me like a somewhat myopic improvement which
This will directly cut Google's bandwidth bills. And they can roll it out instantly to millions of Android phones. It's an open standard and better than JPG, although maybe not as good as it would be if software patents didn't exist. The extra legal risk to Google is nil because it uses technology already present in VP8. I would think it would be obvious, but apparently it needs to be pointed out: when you see an opportunity to cut expenses with absolutely no risk-- you take it!
One format to encode them all Posted Oct 1, 2010 23:58 UTC (Fri) by man_ls (subscriber, #15091) [Link] PNG already provides lossless, for the small number of people who want that.I assume you mean the "small number that want lossless photographs", not the huge number that want lossless icons. Having support for lossless pictures would be a great deal in digital photography, instead of a myriad of RAW formats. But I suspect the point is rather to be able to approach lossless as much as you want. JPEG maxes out at a point where files are huge but artifacts are still there. Having no upward limit (but the 100% lossless point) might be quite useful. Not to speak about 16 or 32 bits per channel... the possibilities are huge. Besides, if the format is cleverly coded, it might provide good support for lossless icons. Having just one format in a page might simplify some work flows.
Popularity of optimization Posted Sep 30, 2010 22:50 UTC (Thu) by mjr (guest, #6979) [Link]
I don't have any hard data but I don't see most people optimizing their images very much. Take gif vs png as a close enough comparison; people still use gif even if they could get noticable (often dual-digit percentage with no loss, period) gains in space, nowadays with pretty much no reduction in support. And of course, there are the other lossy schemes that have come up after base jpeg and seen little use (on the web at least).
Maybe the time is slightly more ripe now patent-wise, taking into account both some of them expiring and the WebM team presumably designing around existing ones, but I'm still not really sure people are gonna jump on the "yay, a slightly less space consuming option for jpeg that has almost no support" bandwagon very readily.
Popularity of optimization Posted Sep 30, 2010 23:41 UTC (Thu) by mjr (guest, #6979) [Link]
As a tired side note on the lack of optimization on the web and a commentary on how I really couldn't be arsed to go to sleep right now even though I really should, I optipng -o7'd the LWN.net corner image.
Turns out it could trivially be reduced by 21.37%, which comes to a whopping 2821 bytes! Just imagine the bandwidth savings achievable here. (The bulk of the reduction probably comes from the automatic removal of the completely superfluous alpha channel.)
Hope this helps with the operating costs of LWN!
Popularity of optimization Posted Oct 1, 2010 6:39 UTC (Fri) by psn (subscriber, #57668) [Link]
Last-Modified: Fri, 04 Sep 2009 16:35:13 GMT
I suspect that any regular reader has the image cached.
Popularity of optimization Posted Oct 4, 2010 15:42 UTC (Mon) by liljencrantz (subscriber, #28458) [Link]
If LWN would decide to reduce the size of the icon, lots and lots of people would need to reload it, causing a large, temporary bump in site traffic. Is the long term gains large enough to offset the initial traffic hit?
Popularity of optimization Posted Oct 4, 2010 15:49 UTC (Mon) by johill (subscriber, #25196) [Link]
I'm not so sure that matters as much as you think it does. For example, http://wireless.kernel.org/moin/linuxwireless/img/header.png has
Last-Modified: Mon, 29 Jan 2007 11:04:48 GMT
yet still accounts for 11.5GiB traffic to the site.
PNG saving and optimization Posted Oct 4, 2010 19:29 UTC (Mon) by mjr (guest, #6979) [Link]
Fist, my comment about the corner icon was, of course, mostly in jest - even if it does, in a very small part, illustrate that size optimality isn't something that everyone pays a lot attention to. (Not that it's a huge deal, really, just a fact of life.)
Second, amusingly the header.png you link also has a useless alpha channel, and optipng -o7 can shave off a whole 17131 bytes (16.22%) off of it. There are probably a lot of such pictures out there - I think gimp produces pngs with empty alpha channels by default when the source image has it, even if the exported (possibly flattened) bitmap doesn't require it. I wonder if that should be a bug.
Anyway, optipng is a nice tool to run at least for images that'll be served lots and lots of times. Even if you don't use the slow, -o7 "obsessive-compulsive" mode, it can often improve on the compression settings a bit. More importantly, it will remove that spurious alpha channel and also do other color type/bit depth/palette reductions where appropriate.
(Being myself a tad OCD, checked that the header.png "only" reduced by 16976 bytes or 16.07% using optipng's fast 8-trial default settings. For comparison, -o7 runs through 240 trials of different setting combinations.)
PNG saving and optimization Posted Oct 4, 2010 19:39 UTC (Mon) by mjr (guest, #6979) [Link]
Oops, misread output, correction: The header.png alpha channel is _not_ useless, and therefore not dropped by optipng either. The improved compression numbers are still correct, though.
PNG saving and optimization Posted Oct 4, 2010 22:09 UTC (Mon) by johill (subscriber, #25196) [Link]
Err, ok, I've optimised the image now with that tool (fwiw, back when it was created, I could only find pngcrush to use). But anyway, that wasn't really my point -- my point was that caching doesn't seem to play as big a role as one might be tempted to think.
PNG saving and optimization Posted Oct 8, 2010 23:38 UTC (Fri) by man_ls (subscriber, #15091) [Link] Well, now you have the chance to try it out in practice: has the traffic surged because of the change in the icon? Has it slowed down after everyone cached the new version?
Advdef can squeeze files even more. Posted Oct 6, 2010 7:30 UTC (Wed) by gmatht (guest, #58961) [Link]
"... size optimality isn't something that everyone pays a lot attention to."
Quite right. If they did, they would run "advdef -z -4" after optipng ;)
I can shave another 11k off header.png and 1k off lcorner.png using advdef. The KDE project uses a script "optimizegraphics" to run these two optimizations on their graphics files.
Advdef can squeeze files even more. Posted Oct 6, 2010 7:36 UTC (Wed) by johill (subscriber, #25196) [Link]
Well, maybe our esteemed editor needs to write an article on this, because otherwise nobody's going to even find the tools.... :-)
Note also that you may not always even be allowed to use advdef, because it appears to link to something called MAME, which states "Redistributions may not be sold, nor may they be used in a commercial product or activity." Thus I'd rather stay away from it.
Advdef can squeeze files even more. Posted Oct 6, 2010 8:54 UTC (Wed) by jbh (subscriber, #494) [Link]
It's ok: it appears to be straight GPLv2, plus an exception allowing it to be linked with MAME.
http://advancemame.sourceforge.net/doc-license.html
http://advancemame.cvs.sourceforge.net/viewvc/advancemame...
Popularity of optimization Posted Oct 1, 2010 16:17 UTC (Fri) by arjan (subscriber, #36785) [Link]
well.. google does have nice browser plugins for "how do I optimize the loading speed of my web page".. which includes suggestions to recompress giff files etc.
some webmasters use this, and google uses their "faster loading web pages give higher ad revenue" angle to suggest to webmasters to use these tools.
so not all hope is lost... there's a story on this that goes from the pointy hair to the web monkey to the guy with clue who runs the tool and sees the suggestion.....
Too soon? Posted Sep 30, 2010 22:58 UTC (Thu) by cesarb (subscriber, #6266) [Link]
WebM adoption is still beginning (for instance, Firefox 4 is not out yet), and they go and launch yet another new and improved format everyone should support?
Too soon? Posted Oct 1, 2010 5:06 UTC (Fri) by rahvin (subscriber, #16953) [Link]
WebM is Video, this is still image. Encoding formats for Video and Still images are different if you haven't noticed.
Too soon? Posted Oct 1, 2010 12:59 UTC (Fri) by tialaramex (subscriber, #21167) [Link]
The point I'm sure the grandparent was making is that adoption is slow, it was already slow in 2000 and it's slower now. If you introduce one new cool thing, and everybody agrees that it's cool, and they work hard to get it widely adopted, you may be able to rely upon it in a decade.
But as you introduce more new things that most people don't have, the resistance to them tends to sum, some people who (for rational reasons or not) object to WebM will automatically carry that over to WebP, in addition to people who may see WebP as unnecessary.
IMO WebP is another HTTP/2.0, an "improvement" in technical terms which can't deliver enough benefits to justify the short term pain. Video was a special case - the lack of middle ground between "Theora sucks, and I don't care about patents" and "Patents suck, and Theora's fine" left a niche for WebM that may (it remains to be seen) make it mainstream. Also Google has Youtube, and there is no Youtube equivalent for still images, the most popular image hosting sites contain a small fraction of the web's images, whereas Youtube dominates web video.
Too soon? Posted Oct 1, 2010 19:10 UTC (Fri) by MattPerry (guest, #46341) [Link]
> The point I'm sure the grandparent was making is that adoption is slow,
> it was already slow in 2000 and it's slower now.
I think the pace will pick up. There's a push, at least with Firefox and Chrome, to release more often with new features. We might see this in a browser within several months (in Chrome at least).
WebP, a new image format for the Web (The Chromium Blog) Posted Oct 1, 2010 6:16 UTC (Fri) by rvfh (subscriber, #31018) [Link]
The blue behind the football player and the purple of the building in the night are different between the original and processed photos... or is it my Firefox (Maverick RC) displaying them differently for some reason?
WebP, a new image format for the Web (The Chromium Blog) Posted Oct 1, 2010 6:19 UTC (Fri) by rvfh (subscriber, #31018) [Link]
The left hand ones are JPEG (probably original) and the right hand ones PNG, which uses different libs. They should probably re-encode the left-hand ones into PNG with a trusted converter so we can really compare apples to apples.
WebP, a new image format for the Web (The Chromium Blog) Posted Oct 1, 2010 8:10 UTC (Fri) by zdzichu (subscriber, #17118) [Link]
Maybe your Fx is applying color-profile information differently to JPGs and PNGs?
WebP, a new image format for the Web (The Chromium Blog) Posted Oct 1, 2010 12:20 UTC (Fri) by varenet (subscriber, #19900) [Link]
Well, it seems Dark Shikari begs to differ, regarding quality comparisons between JPEG, H264 and WebP...
http://x264dev.multimedia.cx/?p=541
He has nice explanations as to why what's what...
WebP, a new image format for the Web (The Chromium Blog) Posted Oct 1, 2010 17:24 UTC (Fri) by dlapine (subscriber, #7358) [Link]
He's also just a bit oversensitive to visually perceptive differences on his sample photos.
At first glance, looking at both side by side, no noticeable difference. Then, by doing a tab switch on the browser, I began to notice some blurriness in colored areas, but only after close examination.
His other points about lack of functionality are more relevant.
WebP, a new image format for the Web (The Chromium Blog) Posted Oct 3, 2010 11:41 UTC (Sun) by ab (subscriber, #788) [Link]
Grass is hugely different in his frame from the movie taken with analogue camera.
WebP, a new image format for the Web (The Chromium Blog) Posted Oct 4, 2010 14:08 UTC (Mon) by fb (subscriber, #53265) [Link]
FWIW IMO the faces of the two first persons look a lot better at the vp8 image than at the x264.
WebP, a new image format for the Web (The Chromium Blog) Posted Oct 8, 2010 13:56 UTC (Fri) by job (guest, #670) [Link]
I believe the point here is not which format is the best performing, but it it does not compare favorably to JPEG. Even if it does for some material chances are that the differences are slight. It is simply not good enough to replace the old, well understood, well implemented, JPEG.
WebP, a new image format for the Web (The Chromium Blog) Posted Oct 3, 2010 13:58 UTC (Sun) by Velmont (guest, #46433) [Link]
It's been updated, and shows the newest Theora Ptalabvrom actually beating VP8! Which is quite amazing given the tight constraints of the Theora format.
I never stopped loving Theora. I still use it for all my video-on-web. WebM is just slower and doesn't bring any benefits at all.
WebP, a new image format for the Web (The Chromium Blog) Posted Oct 5, 2010 12:49 UTC (Tue) by bawjaws (guest, #56952) [Link]
From an earlier post of his, titled "How to cheat on video encoder comparisons" Dark Shikari points out that he sometimes uses specific clips to highlight certain features of codecs.
http://x264dev.multimedia.cx/archives/472
He specifically mentions (in Subtle Cheating, item d.) using "parkrun" as a good test clip for adaptive quantization, one that he specifically tuned for. In the post you link to he is using a frame from the very similar "parkjoy" clip to make the same point about the existing WebP encoder (i.e. not the format)'s current lack of adaptive quantization. But, as he says:
"... claiming that either is representative of most real content and thus can be used as a general determinant of how good encoders are is of course insane."
The subtlety of his argument (in both this and his WebM review) seems to have been lost on many people and so this insanity has become common with his stills being widely touted as proving that WebP/M looks "crappy".
Despite his seeming annoyance at WebP, he himself was previously suggesting a still image format based on H.264 frames would be a good idea. Since he's also pointed out that WebM (and therefore WebP) is essentially an H.264 clone, it can't be that far away from what he suggested could be done with current H.264 tech, claiming it would beat JPEG by 2x or more (see para beginning "JPEG2000 is a classic example"):
http://x264dev.multimedia.cx/archives/472
The article is actually about the problems with wavelet compression and why JPEG 2000 and Dirac are struggling to live up to their potential, but the comment thread in particular is interesting as you get to see all the various WebP rivals (JPEG2000, JPEG-XR, DLI) that are currently being touted as obviously better than WebP being roasted for generally not being as good as JPEG (or alternatively so compute intensive that "you can fry an egg on your desktop") by random compression nerds many months before Google made it a political battle by actually implementing and releasing something that has a vague chance of adoption.
|
|||||||||||||
