pngquant 2.17.0 是命令行的 PNG 压缩工具,压缩包 377304 字节,解开之后 pngquant.exe 加上几个 DLL,不装运行库就能用。

它要解决的是:截图、生成的设计稿、导出的图表,PNG 动辄几 MB,上传慢、网页加载慢,而另存为 JPEG 又会把文字边缘弄糊。

这次拿一张 6400×2160 的真实屏幕截图做压缩,量了体积变化和耗时,也试了三种不适合它的图,结果值得单独说。

一个 377304 字节的压缩包

体积小得几乎不像一个工具,解压后是主程序加两个 DLL。

项值说明
压缩包377304 字节pngquant-windows.zip
版本2.17.02021 年 9 月构建
依赖无需运行库VC 运行库已静态链接
测试素材6400×2160 截图源文件 4000076 字节

377 KB 换掉几 MB 的图片

它做的是调色板量化:把 24 位真彩色降到 8 位(256 色),再配合抖动算法保住观感。所以压缩比通常在三成到七成之间,取决于原图有多少种颜色。

版本停在 2021 年

2.17.0 是最后一个稳定版,之后没有大更新。算法本身成熟,格式没变,用起来不觉得旧。

截图从 4000076 压到 1882190

一张双屏拼接的桌面截图,压缩后体积减了 53%。

项值
源文件4000076 字节(6400×2160)
质量区间 60-901882190 字节,减 52.9%
耗时2903 毫秒
质量区间 70-951882190 字节,与上一档完全一致
pngquant 2.17.0 在 Windows 控制台里的实测输出:窗口标题为 Administrator: pngquant 2.17.0,先列出源文件 shot.png 的 4,000,076 字节,随后一行压缩质量 60-90 的提示,最后列出产物 out1.png 为 1,882,190 字节

两档质量给出相同的文件

60-90 与 70-95 的输出字节数一模一样,都是 1882190。原因是这张图的颜色种类本来就少于 256,量化时没有触发上限,质量区间设多高都不影响结果。

2.9 秒花在量化与重写上

6400×2160 是 1382 万像素,2.9 秒意味着每秒处理约 476 万像素。同样尺寸的图批量处理一百张,大概要五分钟。

三种图不该用它

它对颜色数量敏感,碰上某些类型的图会得出反效果。

图的类型结果原因
纯噪声图(34 MB)退出码 99,拒绝输出量化后质量低于设定下限,它宁可不做
8 位纯渐变图(30525 字节)变成 1750020 字节,涨 57 倍原图只有几十种颜色,压缩后要写调色板与抖动噪声
已经是 256 色的 PNG几乎无变化没有可再压缩的空间

退出码 99 是它的保护机制

碰到质量达不到下限的图,它直接失败而不是硬压。批量脚本里要把 99 当成"跳过"而不是"出错",否则一堆噪声图会让整个任务报错退出。

纯渐变图会变大,这点反直觉

30525 字节的渐变图压完是 1750020 字节。原图用 24 位色但颜色呈规律过渡,PNG 的无损压缩本来就压得很好;量化成 256 色后必须加抖动噪声,反而压不动了。

批量用的写法

单张手动跑没意义,它的价值在循环里。

参数作用
--force输出文件已存在时覆盖,不加会跳过
--quality=60-90质量区间,低于下限就放弃
--output指定输出路径,不写就原地改名
--skip-if-larger压完更大就丢弃结果,保留原图

--skip-if-larger 是防翻车的开关

加上它之后,渐变图那类"压完更大"的情况会被自动跳过,原图保留。批量处理各种来路的截图时,这个参数应该默认带上。

不加 --force 会静默跳过

输出文件已存在时它不报错,直接跳过。脚本里重复跑同一批图,看到"没变化"其实是没执行,加 --force 才覆盖。

什么场景值得上

手上有一堆截图或界面图,要发到网页上、又不想糊掉文字的时候。

场景合适度说明
压缩屏幕截图高实测减 52.9%,文字边缘仍清晰
压缩 UI 设计稿高色块与小字是它的强项
压缩照片低照片该用 JPEG,量化会有色带
压缩纯渐变或图表低可能变大,用 oxipng 那类无损工具更合适

它和无损压缩的分工

pngquant 是有损的:降到 256 色,换来大幅减体积。要完全无损、只重排压缩块,得用 oxipng 或 optipng 这类工具。截图用 pngquant,线框图与图标用无损。

授权与费用

GPL-3.0 与商业双许可,个人与非商业使用免费,闭源商业分发需要单独授权。源码在 GitHub 上,主要语言 C。