Posts Tagged webm

A small WebP test

I was quite intrigued by the WebP image encoding scheme created by Google, and based on the idea of a single-frame WebM movie. I performed some initial tests during initial release, and found it to be good but probably not groundbreaking. But I recently had the opportunity to read a blog post by Charles Bloom with some extensive tests, that showed that WebP was clearly on a par with a good Jpeg implementation on medium and high bitrates, but substantially better for small bitrates or constrained encodings. Another well executed test is linked there, and provide a good comparison between WebP, Jpeg and Jpeg2000, that again shows that WebP shines – really – in low bitrate condition. So, I decided to see if it was true, took some photos out of my trusted Nokia N97 and tried to convert them in a sensible way. Before flaming me about the fact that the images were not in raw format: I know it, thank you. My objective is not to perform a perfect test, but to verify Google assumptions that WebP can be used to reduce the bandwidth consumed by traditional, already encoded images while preserving most of the visual quality. This is not a quality comparison, but a “field test” to see if the technology works as described. The process I used is simple: I took some photos (I know, I am not a photographer…) selected for a mix of detail and low gradient areas; compressed them to 5% using GIMP with all Jpeg optimization enabled, took notice of size, then encoded the same source image with the WebP cwebp encoder without any parameter twiddling using the “-size” command line to match the size of the compressed Jpeg file. The WebP image was then decoded as PNG. The full set was uploaded to Flickr here, and here are some of the results:


Photo: Congress Centre, Berlin. Top: original Jpeg. middle: 5% Jpeg. Bottom: WebP at same Jpeg size.


Photo: LinuxNacht Berlin. Top: original Jpeg. middle: 5% Jpeg. Bottom: WebP at same Jpeg size.


Saltzburg castle. Top: original Jpeg. middle: 5% Jpeg. Bottom: WebP at same Jpeg size.


Venice. Top: original Jpeg. middle: 5% Jpeg. Bottom: WebP at same Jpeg size.

There is an obvious conclusion: at small file sizes, WebP handily beats Jpeg (and a good Jpeg encoder, the libjpeg-based one used by GIMP) by a large margin. Using a jpeg recompressor and repacker it is possible to even a little bit the results, but only marginally. With some test materials, like cartoons and anime, the advantage increases substantially. I can safely say that, given these results, WebP is a quite effective low-bitrate encoder, with substantial size advantages over Jpeg.

, , ,

1 Comment

On WebM, H264, and FFmpeg implementation

 I was recently reminded by Gregory Maxwell of Xiph about the new, non-Google implementation of VP8 done within the context of FFmpeg, and many commenters on Slashdot observed that the fact that the implementation shares lots of code with the H264 part is further demonstration that VP8 is infriging on MPEG-LA held patents.

Actually, there is nothing in the implementation that suggests this, only the fact that some underlying alogrithms are similar (but not identical). For example, the entropy coder is quite similar, and it certainly helps to reuse some of the highly optimized librarties that are within FFMPEG, this is however no indication of patent infringement. What is certain, is the fact that I suspect that libVPX (Google implementation) will remain the “official” one, because there is no guarantee that in the alternative implementation the current IPR safeguards and efforts to avoid existing patents will be done properly. In fact, some of the obvious “missing optimizations” both in the decoder and encoder are clearly done to avoid patents, and this means that Google can be reasonably sure of being safe from IPR claims for the current code drop. If a FFMPEG developer implements some optimization (especially in the encoder) that actually implements a claimed part of a current patent you can end up with a freely implemented source code that implements an IPR-covered claim, like most of FFMPEG actually.

So, to end up this brief post: the existence of a parallel implementation of libvpx is a good thing; the fact that it shares lots of code with FFMPEG is no proof of IPR infringement, but on the other hand it is probably safer to use the libvpx one from Google, as it seems that it was developed explicitly to avoid existing IPR issues.

, ,