为什么 Zipic 保留了 libwebp，却自研了 AVIF 编码器

Zipic 用 Google 的 libwebp 处理 WebP，但在发现 libavif 无法正确保留 iPhone HDR 照片信息后，自研了 avifoptim。两个截然不同的工程决策背后的逻辑。

多数图片压缩应用不自己写编码器——链接几个开源库就发版了。Zipic 在大部分格式上反过来做：六条压缩管线跑的是从头搭建的引擎。但 WebP 例外，Zipic 选择继续用 Google 的 libwebp。有意思的是，AVIF 最初也走同样的路——直到用户的 iPhone HDR 照片暴露了标准库解决不了的问题。这篇文章解释这两个决定，也聊聊在 macOS 上选 WebP 编码器和 AVIF 编码器时该考虑什么。

全景：六种格式自建，一种借用

Zipic 处理十一种图片格式。其中六种——JPEG、PNG（含 APNG）、GIF、SVG、PDF、AVIF——由 Zipic 自研的压缩引擎负责。每套引擎的诞生，都是因为当时的开源方案在输出质量、格式覆盖或兼容性上存在 Mac 用户能感知到的问题。

WebP 走的是另一条路，Zipic 直接集成一个开源库：

libwebp — Google 官方的 WebP 编解码库

剩余格式（HEIC、TIFF、JPEG-XL）依赖 Apple 系统框架或其他成熟库。

WebP 保留了第三方库，AVIF 最终换成了自研。两个决定各有各的原因。

libwebp：站稳脚跟的标准库

libwebp 从 2010 年 Google 发布 WebP 格式时就开始开发，十五年过去了，它至今仍是唯一一个生产级的 WebP 编码器。当前稳定版是 1.6.0（2025 年 6 月），近年来每 6–12 个月发布一个新版本。

三个事实让 libwebp 稳坐不动：

它内嵌在 Chrome 里。 每个 Chrome 版本都包含 libwebp。Google 浏览器团队每天都在用真实内容测试它。Bug 很快暴露，边界情况有人处理，安全补丁几天内就能发出。任何独立团队都复制不了这个反馈循环。

它就是格式标准本身。 WebP 是 Google 的格式，libwebp 是参考编码器。别的编码器要想替代它，就必须产出完全一致的解码结果——做到这一点需要逆向工程，还要跟上 Google 的每次迭代。这件事的投入产出比接近零。

许可证没有商业障碍。 BSD 3-Clause，分发和商用没有任何限制。

WebP 目前的全球浏览器支持率超过 95%。在 Zipic 里把图片转成 WebP，产出的文件来自 Chrome、Android、几乎所有 CDN 背后那同一个编码器。自建替代编码器不会压出更小的文件，也不会更快，反而每次上游更新都要跟进维护。关于 WebP 格式本身，见 WebP 是什么？。

libwebp 没有问题，就不需要替换。

AVIF：“技术上合规”不等于”实际能用”

Zipic 最初用 AOMedia 的 libavif 来处理所有 AVIF 编码。libavif 在 API 层面完整支持 HDR 和 Gain Map。标准 SDR 图片没问题，很多 HDR 工作流也跑得通。真正的问题比”缺少功能”更隐蔽。

现在的 iPhone 拍照会带上 HDR Gain Map——一种嵌入式色调映射数据，让同一张照片在 HDR 和 SDR 显示器上都能正确呈现。Adobe Camera Raw 和 Lightroom 导出的文件也有类似结构。这些 HDR 照片遵循 ISO 21496-1 标准，生成它们的应用在写入 AVIF 文件容器时采用一种特定的格式。

libavif 的编码器写入容器时用的是另一种格式。两种格式都是合规的 AVIF——规范允许任一种布局。但 Safari、照片 App 和其他 HDR 应用在解析时使用严格模式，只认 Apple 和 Adobe 工具产出的那种容器格式。当 libavif 重新编码这些文件时，像素数据没问题，但容器结构变了——输出文件在这些关键应用里不再被识别为 HDR。

站在用户的角度，这看起来就是 bug：用 Zipic 压缩一张 iPhone HDR 照片，在照片 App 或 Safari 里打开，HDR 效果没了。数月来持续的用户反馈确认了这个规律。编码在技术上合规，但在 HDR 工作流里根本跑不通。

这不是 Zipic 调调参数或换个 API 调用就能解决的事。容器格式由 libavif 编码器内部决定。摆在面前的选项是：等上游改（没有时间表）、发版时 HDR 在关键应用里丢失（不可接受）、或者自己做一个编码器，让输出的容器格式满足这些应用的要求。

avifoptim：为保留该保留的东西而生

Zipic 1.9.5 引入了 avifoptim——一个围绕一条原则打造的 AVIF 编码器：输入什么信息，输出就必须完整保留什么信息。HDR 元数据、Gain Map 参数、色彩配置文件，全部在压缩过程中完整保留。

具体来说：

iPhone HDR 照片 保留了 Gain Map。压缩后的文件在照片 App 或 Safari 里打开，在支持 HDR 的显示器上仍然以 HDR 呈现。
Adobe Camera Raw 和 Lightroom 导出文件 的色调映射数据在压缩管线中完整保留。
色彩准确性 全面提升，不限于 HDR 内容。SDR 图片在质量与体积的平衡上也更稳定。

“Zipic is the only tool I’ve found that can convert 10-bit HDR gain-map images to AVIF while preserving metadata.” — Adam Sébire，摄影师，2025 年 12 月至 2026 年 5 月间完成了四轮 HDR 测试

AVIF 编码基于 AV1——一种由开放媒体联盟设计的视频编码格式。AV1 的背后是七家创始公司（Amazon、Cisco、Google、Intel、Microsoft、Mozilla、Netflix），后来 Apple、AMD、NVIDIA 等也陆续加入。光是规范文档就长达 681 页。要做 AVIF 编码器，就得直面这个级别的复杂度。Zipic 做出这个投入，是因为越来越多的 HDR 照片经现有库编码后，虽然技术上合规但在关键应用里用不了。关于 AVIF 格式本身，见 AVIF 是什么？。

真正的规律：能用就用，不行就建

这些决定背后的规律不是”一律自建”，也不是”一律采用”。而是：

先用最好的现有方案。当它让用户失望时，自己做。

libwebp 从没让 Zipic 的用户失望过。输出正确，性能够好，Google 的维护规模是任何独立团队都复制不了的。没有理由替换。

libavif 输出的 AVIF 技术上合规，但它写入的容器格式不被 Safari、照片 App、Adobe 工具识别为 HDR。用户看到的是：iPhone HDR 照片压缩之后 HDR 没了。这个差距让自研编码器成为必要。

另外五套引擎也是同样的道理：

现有 JPEG 编码器在常用压缩级别上的质量与体积平衡仍有提升空间。Zipic 的渐进式 JPEG 管线针对这一点做了优化。
PNG 压缩——尤其是 APNG 这种多数工具直接忽略的动画扩展——在 macOS 上没有一个工具能同时处理静态帧和动画帧。同一套引擎也驱动了 ICNS 图标优化。
GIF 压缩领域，gifski 等工具专注于视频转 GIF，但无法压缩已有的 GIF 文件。
macOS 上的 SVG 优化此前没有原生方案——所有选项都依赖 Node.js。Zipic 的引擎在 macOS 上原生运行，零外部依赖。
PDF 压缩长期依赖 Ghostscript，一个并非为 macOS 批量工作流设计的工具。Zipic 的引擎实现了批量 PDF 压缩，完全不依赖 Ghostscript。

每套自研引擎都是因为某个具体的用户问题没有现成方案。每个保留的第三方库，都是因为它好用。