今天看到个google中文blog上面的一篇文章,看到其中有这么一段话
*2016 年,我们了解到,PNG 无损压缩得到了很大改进,而 Google 的 zopfli 工具是目前最先进的压缩工具。
于是,我开始看看什么是zopfli,开源项目的地址是:https://github.com/google/zopfli
步骤一
首先现在源代码,并解压,打开解压的目录,然后根据文档说明
The source code of Zopfli is under src/zopfli. Build instructions:
To build zopfli, compile all .c source files under src/zopfli to a single binary
with C, and link to the standard C math library, e.g.:
gcc src/zopfli/*.c -O2 -W -Wall -Wextra -Wno-unused-function -ansi -pedantic -lm -o zopfli
A makefile is provided as well, but only for linux. Use "make" to build the
binary, "make libzopfli" to build it as a shared library. For other platforms,
please use the build instructions above instead.
Zopfli Compression Algorithm was created by Lode Vandevenne and Jyrki
Alakuijala, based on an algorithm by Jyrki Alakuijala.
在Linux环境中,执行以下命令:
make zopfli
make zopflipng
如果不想编译某些命令,可以全部清理,只编译你所需要的命令
make clean//清理命令
步骤二
编译完成之后,该命令怎么用呢?以编译的zopflipng命令为例子:使用命令行:
zopflipng -h
d查看相应的说明文档,比如:
ZopfliPNG, a Portable Network Graphics (PNG) image optimizer.
Usage: zopflipng [options]... infile.png outfile.png
zopflipng [options]... --prefix=[fileprefix] [files.png]...
If the output file exists, it is considered a result from a previous run and not overwritten if its filesize is smaller.
Options:
-m: compress more: use more iterations (depending on file size)
--prefix=[fileprefix]: Adds a prefix to output filenames. May also contain a directory path. When using a prefix, multiple input files can be given and the output filenames are generated with the prefix
If --prefix is specified without value, 'zopfli_' is used.
If input file names contain the prefix, they are not processed but considered as output from previous runs. This is handy when using *.png wildcard expansion with multiple runs.
-y: do not ask about overwriting files.
--lossy_transparent: remove colors behind alpha channel 0. No visual difference, removes hidden information.
--lossy_8bit: convert 16-bit per channel image to 8-bit per channel.
-d: dry run: don't save any files, just see the console output (e.g. for benchmarking)
--always_zopflify: always output the image encoded by Zopfli, even if it's bigger than the original, for benchmarking the algorithm. Not good for real optimization.
-q: use quick, but not very good, compression (e.g. for only trying the PNG filter and color types)
--iterations=[number]: number of iterations, more iterations makes it slower but provides slightly better compression. Default: 15 for small files, 5 for large files.
--splitting=[0-3]: ignored, left for backwards compatibility
--filters=[types]: filter strategies to try:
0-4: give all scanlines PNG filter type 0-4
m: minimum sum
e: entropy
p: predefined (keep from input, this likely overlaps another strategy)
b: brute force (experimental)
By default, if this argument is not given, one that is most likely the best for this image is chosen by trying faster compression with each type.
If this argument is used, all given filter types are tried with slow compression and the best result retained. A good set of filters to try is --filters=0me.
--keepchunks=nAME,nAME,...: keep metadata chunks with these names that would normally be removed, e.g. tEXt,zTXt,iTXt,gAMA, ...
Due to adding extra data, this increases the result size. Keeping bKGD or sBIT chunks may cause additional worse compression due to forcing a certain color type, it is advised to not keep these for web images because web browsers do not use these chunks. By default ZopfliPNG only keeps (and losslessly modifies) the following chunks because they are essential: IHDR, PLTE, tRNS, IDAT and IEND.
Usage examples:
Optimize a file and overwrite if smaller: zopflipng infile.png outfile.png
Compress more: zopflipng -m infile.png outfile.png
Optimize multiple files: zopflipng --prefix a.png b.png c.png
Compress really good and trying all filter strategies: zopflipng --iterations=500 --filters=01234mepb --lossy_8bit --lossy_transparent infile.png outfile.png
yi以图片:为例子,该图片原图为95kb,执行压缩命令后
zopflipng 0805501.png out.png
y压缩速度比较慢,压缩完成后的输出日志为:
Optimizing 0805501.png
Input size: 95004 (92K)
Result size: 86033 (84K). Percentage of original: 90.557%
Result is smaller
看可以看出,压缩后的png比原图缩小了90.557%