LWN.net Logo

Using Google's WebP Image Format with Open Tools on Linux (Linux.com)

Nathan Willis investigates Linux tools for using the WebP image format over at Linux.com. WebP is a lossy image format (like JPEG) that was introduced by Google back in September. "WebP compression is essentially an adaption of a single frame of WebM video. It, too, breaks the image into blocks (although 4-by-4 in size, rather than 8-by-8), but in place of JPEG's DCT [Discrete Cosine Transform] and high-frequency bit-chopping step, it uses the intra-frame coding algorithm from WebM. Intra-frame coding is the coding down within a single frame, as opposed to between two consecutive frames, and WebM's method involved constructing a prediction for each block based on the blocks adjacent to it. The encoder saves the predictions and the differences between the predictions and the real input blocks in the output file — if prediction is going well, as it should for most continuous-tone images like photos, the output is smaller than the raw input — and the result compressed with lossless techniques."
(Log in to post comments)

Using Google's WebP Image Format with Open Tools on Linux (Linux.com)

Posted Mar 25, 2011 15:18 UTC (Fri) by piggy (subscriber, #18693) [Link]

> WebP is a lossy image format (like JPEG)
...
> — and the result compressed with lossless techniques."

Does anyone else find this juxtaposition confusing? Looking at http://code.google.com/speed/webp/ it's clear that the codec is lossy.

Using Google's WebP Image Format with Open Tools on Linux (Linux.com)

Posted Mar 25, 2011 16:02 UTC (Fri) by fsphil (guest, #44932) [Link]

If the format is anything like JPEG then the lossless part they talk about is the last stage (after the lossy bit) when the bitstream is passed through some kind of entropy encoding, like Huffman coding or arithmetic coding.

Using Google's WebP Image Format with Open Tools on Linux (Linux.com)

Posted Mar 25, 2011 18:02 UTC (Fri) by endecotp (guest, #36428) [Link]

>> WebP is a lossy image format (like JPEG)
>...
>> — and the result compressed with lossless techniques."
>
> Does anyone else find this juxtaposition confusing?

Not until you elided a chunk describing the main part of the process, no.

Nonplussed by samples

Posted Mar 26, 2011 15:07 UTC (Sat) by tack (subscriber, #12542) [Link]

Google has a small gallery comparing JPEG and WebP, and I'm very confused by what they're trying to show. Comparing codecs is, to borrow from Snape, a bit of a subtle science and exact art, but in order to be able to make any useful statements, you need to either compare quality at the same file size, or compare file size at the same quality.

Yet the examples on the gallery are clearly different qualities at different file sizes. Or, if they are intended to be the same quality, I'm not impressed by what I see in WebP. There's much less ringing in WebP compared to JPEG, but at the expense of a considerable amount of detail. Worse, the WebP samples exhibit awful DCT blocking artifacts and a bit of banding, neither of which are present (or nearly as apparent) in the JPEG samples.

Nonplussed by samples

Posted Mar 26, 2011 15:40 UTC (Sat) by jthill (guest, #56558) [Link]

Going through them, the thing I noticed was that the quality difference is as you describe when zoomed in, but unzoomed any differences are completely imperceptible -- repeating ctrl-tab at any rate, the image is stable. I'm looking with the 11.0.696 chrome release.

Nonplussed by samples

Posted Mar 26, 2011 20:37 UTC (Sat) by mcelrath (guest, #8094) [Link]

Looking at the first image (mountain + river) the jpeg has the sky smooth, but is clearly blocky in higher contrast areas (e.g. bank of the river, mountain-sky interface). The webp is blocky on the sky, and somewhat less blocky on high contrast areas.

I'm not sure this is an improvement. The banding/blockiness over smooth gradient-like areas is very noticeable, and takes up a lot of image real estate. The high contrast edges are improved, but not by a lot...

Nonplussed by samples

Posted Mar 29, 2011 2:33 UTC (Tue) by hamjudo (subscriber, #363) [Link]

It looks like they attempted to compress until there were barely visible artifacts in both pictures. My laptop monitor is not good at color reproduction, thus the banding is hard to detect on it. The high contrast jpeg artifacts are much easier to see (on this monitor).

I strongly suspect that I will get much different results when I use a different monitor (the wetware in my head is even more significant in the image evaluation process, but replacing that is difficult). I assume that the quality appeared approximately equal on quite a few monitors, as viewed by a significant user population.

The better news, is that the format is free of IP encumbrances.

Nonplussed by samples

Posted Mar 30, 2011 13:03 UTC (Wed) by jmalcolm (guest, #8876) [Link]

I imagine what they are trying to show, since it is the stated purpose of the format, is that WebP is "equivalent" quality at smaller file sizes. I think what they are assuming is that WebP is "good enough" that users will not notice the difference with JPEG.

Since WebP uses the same tech as WebM, I am going to assume that improvements in WebM will also benefit WebP. I expect WebM to be quite popular so WebP may actually improve quite a lot over time.

JPEG is not something that people are scrambling to get away from. Still, it is nice to have a completely free and open option out there. Competition is a good thing.

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