Image Compression using WebP technology

Question

WebP technology is use for both lossy and lossless image compression which compress image more than "JPEG" and I'm studying in image compression technique. so if any one can provide me clear algorithm for WebP image compression it would be help full to me.

Answer 1

Oh well, providing the entire algorithm for both lossy and lossless compression including all variants in full detail is well beyond a single answer on this forum. Google provides specifications for the lossy and lossless bit streams for free. However, the latter is quite incomplete, inaccurate, and partially even wrong. You will have a hard time implementing a codec based on this spec, and it's indispensable to study quite some source code as well.

I can give you here at least some details about the lossless format:

• Like PNG, which uses the ZIP DEFLATE compression algorithm, WebP uses Huffman encoding for all image information, too. Actually, much of WebP's compression gain stems from cleverly employing Huffman coding. Many details are obviously borrowed from DEFLATE, i.e. limiting the code size to 15 bits, and encoding the Huffman Alphabets with yet another Huffman code, which is almost the same as DEFLATE uses.
• Additional compression is achieved by LZ77 sliding-window compression, and an optional color cache of size 2..2048, comprising the most recently used colors. The encoder is free to decide which one to use. Both can be mixed. However, I've found in my tests that this can be detrimental to the compression ratio. Photographic images usually compress fine with a big color cache, and when using the cache, it's usually better to use literal ARGB encoding all the time for pixels not present in the cache, rather than using LZ77 backward references.
• While the use of LZ77 compression is pretty much the same as in DEFLATE, Google's specification is not based on bytes, but pixels. That is, ARGB quadruples are compressed, rather than individual A-R-G-B bytes. Moreover, WebP allows backward reference lengths up to 4096 pixels and reference distances up to 1048576 - 120 pixels, which is quite beyond the DEFLATE limits. Another benefit is obtaind by using separate Huffman alphabets for the ARGB channels.
• Like PNG, the WebP LZ77 compression has a RLE (Run Length Encoding) feature, which is the result of clever handling of a special case, when the reference length exceeds the reference distance. In this case, the available bytes are copied over and over again, until reaching the specified length. I've found that using this feature yields great compression for "artificial" images with long runs of the same color. However, it conflicts with the color cache, which will generate quite efficient Huffman codes for such runs. Based on my preliminary tests, the color cache outperforms the RLE feature.
• Like PNG, WebP doesn't perform well on raw ARGB data. Therefore, both formats allow application of various Transforms on the pixel data, before compression begins. Those transforms really do a great job reducing the variance of the pixel stream and account for a great deal of the resulting comression ratio. WebP defines 13 standard predictor transforms, while PNG has only 4. However, I've found that most of the predictors don't yield much gain, and I usually employ the "Select" filter, which picks either the pixel to the left or above, whichever appears to be more appropriate as predictor. As with PNG, the simple filters frequently are better than the complex ones.
• Besides predictor transforms, WebP offers some other transforms, of which I've tried the "Subtract Green" only, which attempts to decorrelate the RGB channels by subtracting G from both R and B for each pixel. Indeed I've observed some benefit, when applied after the predictor. If applied before, it may have a negative impact on photographic images.
• WebP uses 5 separate Huffman codes for the bitstream: One for the green channel, the LZ77 length codes, and the color cache indexes, one for the red channel, one for the blue channel, one for the alpha channel, and one for the LZ77 distance codes. This is a clever design, since the information in the ARGB channels might be quite uncorrelated, so merging them into a single alphabet can be suboptimal.

WebP lossless offers a wide range of options that can be combined and tweaked to the max. However, in my opinion, most of the combinations are not worthwhile to test. Based on my observations, compression is usually good with the following defaults:

• Use the "Select" predictor.
• Apply the "Subtract Green" transform.
• Use a color cache with 2048 slots.
• If the current pixel is not in the cache, encode it as literals.