- #Xnconvert compression method webp full
- #Xnconvert compression method webp code
- #Xnconvert compression method webp zip
If applied before, it may have a negative impact on photographic images. Indeed I've observed some benefit, when applied after the predictor.
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. As with PNG, the simple filters frequently are better than the complex ones. 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. WebP defines 13 standard predictor transforms, while PNG has only 4. 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. Therefore, both formats allow application of various Transforms on the pixel data, before compression begins. Like PNG, WebP doesn't perform well on raw ARGB data. Based on my preliminary tests, the color cache outperforms the RLE feature. However, it conflicts with the color cache, which will generate quite efficient Huffman codes for such runs. I've found that using this feature yields great compression for "artificial" images with long runs of the same color. In this case, the available bytes are copied over and over again, until reaching the specified length. 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. Another benefit is obtaind by using separate Huffman alphabets for the ARGB channels. 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. That is, ARGB quadruples are compressed, rather than individual A-R-G-B bytes. While the use of LZ77 compression is pretty much the same as in DEFLATE, Google's specification is not based on bytes, but pixels. 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. However, I've found in my tests that this can be detrimental to the compression ratio. The encoder is free to decide which one to use. Additional compression is achieved by LZ77 sliding-window compression, and an optional color cache of size 2.2048, comprising the most recently used colors. #Xnconvert compression method webp code
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. Many details are obviously borrowed from DEFLATE, i.e. Actually, much of WebP's compression gain stems from cleverly employing Huffman coding.
#Xnconvert compression method webp zip
Like PNG, which uses the ZIP DEFLATE compression algorithm, WebP uses Huffman encoding for all image information, too.I can give you here at least some details about the lossless format: 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.
However, the latter is quite incomplete, inaccurate, and partially even wrong. Google provides specifications for the lossy and lossless bit streams for free.
#Xnconvert compression method webp full
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.
0 kommentar(er)
