Hi, I was puzzled by this "yet another image format" from Google and did some quick research tonight. Not much turned up in the data provided by Google and, as always, the best starting point is Wikipedia: http://en.wikipedia.org/wiki/WebP . Short but to the point.
The critical part is the Math: WebP is based on block prediction and encoding, something that works well for compressing frame to frame videos but one has to wonder about still images. Why would blocks be predictable spatially? Similar textures? May be but loss of precision would be horrendous, something that I don't thing the JPEG (a group of Pro Photographers) would swallow. Besides, it reminds me a lot about fractal compression of the mid 90's and we all know how this ended... Then, if prediction fails, WebP falls back to DCT so no better than classical JPEG and the blocking artifacts are as "good" as what JPEG gives us... a problem that, precisely, wavelet compression (used in jpeg2000) solved. It seems to me that, as far as encoding differences from levels to levels, wavelets do that uniformly on the whole image much better already and its mathematical underpinning is much stronger (see Stéphane Mallat papers' on Optimal Image Compression). Not to mention that wavelet gives us LOD (Level of Details == discard level == subres access) that we *do* use in SL and random spatial access that, unfortunately, we do not use in SL (though we ought to). Anyway, WebP gives us neither one not the other. As for the 39% better compression touted by Google, I fail to see that as a big selling point, especially when taking the huge compression time they apparently experience into account. You also get much better compression rate with jpeg2000 than with jpeg any day. But, even with good old jpeg, if you take the time to compute adapted quantization tables for each image, you would get much better compression rates. Now, no one does this because it takes too long at compress time (which is typically done on cameras...) so everyone uses the same set of "standard" (read "ought to work for all run of the mill picture taking situations") quantization tables. So, if you were to really compare apple to apple, I'm not even sure that WebP is that much better than standard jpeg. More: 8 bits per channel only? That must be a typo... I won't even go down the "raw" and high dynamic range debate familiar to folks with an interest in photography. Well, I don't see why the method can't be extended to 16 bits though. Then this: comparing "visually" differences between JPEG images pulled from the web and reencoded with WebP to judge quality? No seriously, I almost cried... I thought Google had better standards for quality of engineering. What a disappointment. My take: keep on the radar (because it's Google...) but I don't see the urgency to jettison JPEG2000 for static images yet. Cheers, - Merov On Fri, Oct 1, 2010 at 10:45 AM, Tateru Nino <tat...@taterunino.net> wrote: > Hmm. Only supports a single image data chunk and no alpha channels in this > release. True, you could break compatibility and extend it, but I'm not sure > that's really the way to go. Not close to a drop-in replacement yet, even > after banging it on some rocks. > > > On 2/10/2010 3:15 AM, SuezanneC Baskerville wrote: > > Google is putting out a new open source image format, said to offer higher > compression rates than JPEG2000. > > I just thought someone with the appropriate technical knowledge ought to > take a look at in case it might be useful for use in Second Life. > > http://blog.chromium.org/2010/09/webp-new-image-format-for-web.html > > *To improve on the compression that JPEG provides, we used an image >> compressor based on the VP8 codec that Google >> open-sourced<http://blog.webmproject.org/2010/05/introducing-webm-open-web-media-project.html>in >> May 2010. We applied the techniques from VP8 video intra frame coding to >> push the envelope in still image coding. We also adapted a very lightweight >> container based on >> RIFF<http://en.wikipedia.org/wiki/Resource_Interchange_File_Format>. >> While this container format contributes a minimal overhead of only 20 bytes >> per image, it is extensible to allow authors to save meta-data they would >> like to store. >> >> 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. >> * > > > http://code.google.com/speed/webp/ > -- > v i r t u a l w o r l d e n t h u s i a s t > -- http://www.google.com/profiles/s u e z a n n e -- > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges > > > -- > Tateru Ninohttp://dwellonit.taterunino.net/ > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges >
_______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
