Recent Features
| |||||||||||||
Google releases a better compression algorithmGoogle releases a better compression algorithmPosted Feb 28, 2013 23:46 UTC (Thu) by flammon (guest, #807)Parent article: Google releases a better compression algorithm How does it compare to 7z?
(Log in to post comments)
Google releases a better compression algorithm Posted Feb 28, 2013 23:56 UTC (Thu) by boklm (subscriber, #34568) [Link]
see http://zopfli.googlecode.com/files/Data_compression_using... for some comparison with 7zip.
Google releases a better compression algorithm Posted Mar 1, 2013 0:08 UTC (Fri) by Zizzle (guest, #67739) [Link]
Not really.
"7Zip can operate with the deflate format, but it can read and write several other archive formats, and achieve higher compression ratios. In this study we only measured deflatecompatible compression."
I suspect the non-deflate 7-zip or xz would do better than zopfli.
Google releases a better compression algorithm Posted Mar 1, 2013 1:49 UTC (Fri) by rgmoore (subscriber, #75) [Link] This seems like the core of the article. What Google has done is to create a slightly higher compression ratio version of deflate compression. It's like coming out with gzip that goes up to -12 or -15 instead of just -9. It has the advantage of retaining compatibility with existing decompression programs, but it doesn't offer the larger improvements in space efficiency possible by using a more modern compression scheme like xz.
Google releases a better compression algorithm Posted Mar 1, 2013 2:17 UTC (Fri) by rahulsundaram (subscriber, #21946) [Link]
Look at the purpose for which they created it. It doesn't make sense for them to use a newer compression algorithm since they want to retain compatibility.
Google releases a better compression algorithm Posted Mar 1, 2013 9:27 UTC (Fri) by nim-nim (subscriber, #34454) [Link]
Actually, what compression method to use is one of the hot topics of the ietf workgroup currently working on HTTP/2, and Google is a major contributor to those talks. There is no reason for HTTP/2 to use the same algorithms as HTTP/1, and the use-cases presented in the sopfli paper are definitely the same as HTTP/2.
Google releases a better compression algorithm Posted Mar 1, 2013 15:19 UTC (Fri) by jengelh (subscriber, #33263) [Link]
>here is no reason for HTTP/2 to use the same algorithms as HTTP/1
Indeed, and therefore, HTTP/2 could just as well use xz. (Or any other established LZMA-ish compressor, but picking xz would follow suit with gzip, which was also used for files and tarballs.)
That, and LZO for the ones who like a trade-off into speed over ratio.
Google releases a better compression algorithm Posted Mar 2, 2013 7:55 UTC (Sat) by epa (subscriber, #39769) [Link]
Google has a replacement for LZO: http://code.google.com/p/snappy/
Google releases a better compression algorithm Posted Mar 3, 2013 2:08 UTC (Sun) by scientes (guest, #83068) [Link]
xz is officially lzma2, as used the same liblzma as the original legacy lzma1. Basically people used lzma before it was ready, so they renamed the final version to avoid confusion over the incompatibility. lzma is now a symlink to xz.
both lzo and xz are very useful, but for differn't things, lzo is most useful when only using the compressed data once, and xz when it is write-once read-many, so you can afford the high compression times and memory requirements.
Google releases a better compression algorithm Posted Mar 2, 2013 2:31 UTC (Sat) by csigler (subscriber, #1224) [Link]
Google releases a better compression algorithm Posted Mar 1, 2013 2:36 UTC (Fri) by xz (subscriber, #86176) [Link]
You can't imagine how many tools out there are competing to optimize deflate for minimum png file size.
|
|||||||||||||