LWN.net Logo

WebP, a new image format for the Web (The Chromium Blog)

WebP, a new image format for the Web (The Chromium Blog)

Posted Sep 30, 2010 22:33 UTC (Thu) by gmaxwell (subscriber, #30048)
Parent article: WebP, a new image format for the Web (The Chromium Blog)

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. ;)


(Log in to post comments)

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 (subscriber, #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
http://blog.httpwatch.com/2008/10/15/two-important-differ...
etc., etc.

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
> 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.

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.

Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds