一张照片,在 macOS 预览里点导出,跟用 Zipic 压出来,文件大小能差 30%。原因不在质量参数,在底下的编码器。这篇讲清原因,顺便看 Zipic 怎么默认就给你压得更小。
一张图,导出两份 JPEG。摆在屏幕上对着看,分不出哪份是哪份,但一份就是比另一份小一截。这个差距,不在你拉的那个质量滑块上,在滑块背后的 编码器 上。
macOS 预览里点「导出」,出来的 JPEG 就是 libjpeg 写的——一个 30 年前的老工程,今天仍然是浏览器解码的标配。同一张图丢给 Zipic、ImageOptim,或者别的现代 JPEG 工具,文件明显小一截,肉眼看不出差别。像素没变,字节变了。
下面把这件事讲清楚:渐进式 JPEG 跟基线 JPEG 到底差在哪、为什么 Zipic 内置了一份定制版的 JPEG 编码器 zipic-jpeg(基于 MozJPEG——Mozilla 做的那个把 JPEG 压得更小的开源项目)。所有数字都用同一组五张照片测出来。
你应该见过这件事,只是不知道它有名字。
网速慢的时候打开一张大图,画面从上往下一条条出来——这是 基线 JPEG,解码器按字节顺序从头读到尾。
渐进式 JPEG 不一样:第一批字节到了,浏览器就先用这些字节画出整张图的模糊预览,后面字节再让画面一遍遍变清晰。最终画面相同、文件大小相同,差别只在加载体验——你能更早看清图里画的是什么。
今天 Web 上多数 JPEG 都是渐进式,原因就在这里。另外还有一个隐藏好处:渐进式输出能让编码器把数据排得更紧,所以同样质量下渐进式 JPEG 反而通常 更小 一些(百分之几的差距)。下面的实测也能看出来。
JPEG 什么场合该用什么场合不该用,可以读有损压缩与无损压缩对比。
同样的质量档位,两个工具压出来文件能差很多——因为编码器写文件时要做一长串小决策:哪些模式值得优化、数字怎么取整、数据怎么排。多数工具内置的那套(libjpeg-turbo)走的是保守路线。MozJPEG 不一样——这是 Mozilla 做的一份现代 JPEG 编码器。
MozJPEG 用了一种更聪明的取整策略,能在视觉相同的前提下找出最省字节的写法。它还会针对每张图重新算一张压缩表,而不是套一张通用模板。实测下来,普通照片上 MozJPEG 比默认编码器小 20%–30%——视觉看不出区别,只是排得更紧。
代价是速度:MozJPEG 比默认编码器慢 2 到 3 倍,因为每张图都要多花不少时间算。网页素材这种压一次用很久的东西不在乎这点时间;相机一秒拍十几张的连拍就受不了。
这就是 Zipic 默认用的编码器。
zipic-jpeg(命令行里我们叫它 zjpeg)是一份定制版的 MozJPEG。MozJPEG 自己拿来当工具用不太顺手的几个地方,我们顺手都补上了。对你来说重点是三件事:
输出的字节跟 MozJPEG 命令行的产物完全一样。我们没想造一个比 MozJPEG 更好的 JPEG,做的事是把现成最好的这个打包好,让你不用开终端也能用上。
JPEG 的质量参数和文件体积是怎么对应的,Mac 减小 JPEG 文件体积 里有详细说法。
五张源图,长边 1920 像素:一张抽象渐变、一张广角风景、一张自然纹理、一张人像、一张 UI 截图。同样的质量档位,分别用两个编码器各压一遍。
文件大小,渐进式模式:
| 图像 | zipic-jpeg | libjpeg-turbo | 节省 |
|---|---|---|---|
| 抽象渐变 | 36.8 KB | 49.5 KB | −25.7% |
| 风景 | 102.3 KB | 132.7 KB | −22.9% |
| 自然纹理 | 45.9 KB | 62.5 KB | −26.6% |
| 人像 | 47.2 KB | 59.9 KB | −21.3% |
| UI 截图 | 88.3 KB | 111.0 KB | −20.5% |
| 合计 | 320.4 KB | 415.7 KB | −22.9% |
文件大小,基线模式(两边都关闭渐进式):
| 图像 | zipic-jpeg | libjpeg-turbo | 节省 |
|---|---|---|---|
| 抽象渐变 | 38.6 KB | 62.8 KB | −38.5% |
| 风景 | 105.0 KB | 144.8 KB | −27.5% |
| 自然纹理 | 53.4 KB | 81.8 KB | −34.7% |
| 人像 | 50.4 KB | 70.6 KB | −28.6% |
| UI 截图 | 97.2 KB | 132.6 KB | −26.7% |
| 合计 | 344.7 KB | 492.5 KB | −30.0% |
与源图的结构相似度(越接近 1.000 越接近原图):
| 图像 | zipic-jpeg | libjpeg-turbo |
|---|---|---|
| 抽象渐变 | 0.9922 | 0.9924 |
| 风景 | 0.9814 | 0.9828 |
| 自然纹理 | 0.9935 | 0.9939 |
| 人像 | 0.9928 | 0.9924 |
| UI 截图 | 0.9935 | 0.9927 |
默认编码器在五张图里有三张分数高一点,但差距在小数点第三位,肉眼看不到。代价是文件大了 20%–30%。在人像和 UI 截图上,zipic-jpeg 反过来分数更高、文件还更小。
一句话:同样的图,更小的文件,看着没区别。
不用选。把 JPEG 拖进 Zipic,跑的就是 zipic-jpeg。
你选的是 预设 ——一组保存好的目标格式、压缩等级、可选的缩放尺寸、元数据策略——然后 Zipic 把这个预设套到你拖进窗口或者顶部 Notch 的每个文件上。默认就是渐进式输出,不需要单独开。
格式转换走的也是同一套流程。拖一张 HEIC、RAW 或者 PNG 进来,只要选了 JPEG 预设,zipic-jpeg 就用 macOS 原生通道把源图解码,再编成 JPEG,一步搞定。
具体怎么转——RAW 转 JPEG 分享、HEIC 转 JPEG 适配那些还不接受 HEIC 的网站——可以看 RAW 转 JPEG 指南 和图片格式怎么选。
下载 Zipic,拿一个文件夹自己手头的 JPEG 跑一遍,看着它们体积少四分之一,画面看不出差别。第一次压缩跟点一下鼠标的时间差不多。
下载即享 7 天完整 Pro 体验;想继续用进阶预设、预览对比、文件夹监控这些功能,看 Zipic Pro 定价。
预设的完整参考,包括压缩等级对照,在 图片压缩基础指南 里。

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

gifski 是 Mac 上把视频转成 GIF 的好手,但它压不了已有的 GIF、不会批量处理、也不监控目录。本文讲的是 gifski 之外,Mac 上 GIF 工作流该靠谁。

在 Mac 上找 SVG 优化工具?用 Zipic 压缩和优化 SVG 文件——清掉编辑器留下的冗余、从六档强度里选、批量处理整套图标。