TIFF 压缩教程：在 Mac 上大幅减小 TIFF 文件大小

如果你曾经在 Mac 上想 压缩 TIFF ，结果发现压完之后体积几乎没变，那你已经撞上了 TIFF 这个格式最核心的脾气：它从来就不是为”小”而设计的，它是为 无损、忠实、可永久编辑 而设计的。这正是为什么扫描仪、印刷厂和摄影师还在把母片以 TIFF 形式交付——也正是为什么这些文件动辄超过 100 MB ，把每一条经手它们的工作流都拖垮。

这篇文章讲的就是 2026 年在 Mac 上 真正能让 TIFF 文件变小 的两条路径：这个格式允许你做什么、不允许你做什么；以及什么时候”压缩 TIFF”是错问题， 转出 TIFF 才是对答案。

为什么 Mac 上的 TIFF 文件这么大

TIFF 默认就是按完整位深、不强制压缩来存像素的。一句话，麻烦的根源就在这。

随手算一下 Lightroom 或 Capture One 常见的导出参数：

来源	像素	位深	未压缩体积
24 MP 相机，16-bit RGB	~24,000,000	6 字节/像素	~144 MB
12 MP 扫描，16-bit RGB	~12,000,000	6 字节/像素	~72 MB
4×5 大画幅滚筒扫描，8-bit RGB	~150,000,000	3 字节/像素	~450 MB
多页归档 TIFF（约 30 页）	随页数变化	8-bit	200–800 MB

数字不是估的。16-bit TIFF 每个通道 2 字节、三通道共 6 字节/像素，24 MP 算下来就是 144 MB ，还没算容器开销——这个数字在 Lightroom Queen 论坛 上被摄影师反复印证。

再叠上现实里 TIFF 通常会带上的东西：

• 来自图书扫描或批量传真的 多页文档
• Photoshop 合成留下来的 alpha 通道
• Photoshop 保存时勾上”图层”会内嵌的 完整图层
• ProPhoto RGB 或 AdobeRGB 这类 ICC 色彩档案
• EXIF / IPTC / XMP 元数据块
• 新款 iPhone 和索尼机身写入的 HDR gain map 辅助数据

这些都不是冗余——它们正是文件之所以是 TIFF 的理由。它们也正是文件动辄超过 300 MB 的理由。

走进 TIFF 内部：LZW、ZIP 与失效的”质量滑块”

TIFF 是一个容器，不是一个编码器。真正的压缩——如果有的话——是按文件单独选的。Adobe TIFF 6.0 规范（1992 年 6 月）至今仍是权威参考，它把规范分成 Baseline TIFF （所有读取器必须支持）和 TIFF Extensions （可选）两层。摄影师和归档人员在 2026 年真正会用到的两种压缩，恰好都属于 Extensions ：

• LZW（tag value 5） ——加入于 TIFF Revision 5.0（1988 年 10 月）。无损、基于字典，几乎所有 TIFF 读取器都吃，包括古董级的印刷 RIP 。
• ZIP / Deflate（tag value 8） ——和 PNG 与 .zip 归档用的是同一套 Deflate 算法。无损，写入比 LZW 略慢，对照片那种平滑渐变特别友好。

规范里还有别的选项—— JPEG-in-TIFF 、PackBits 、CCITT Group 4 、ZSTD 、WebP ——但 macOS 上的现实是，绝大多数工作流真正能稳定吃下的，只有 LZW 和 ZIP 两个值。两个都是彻底无损的。两个都没有所谓质量滑块。如果某个工具给你看到一个”TIFF 质量”旋钮，它几乎一定在偷偷做下面两件事之一：把文件改写成 JPEG-in-TIFF（大多数印刷厂会拒收），或者干脆什么都没做、指望你不会发现。

让人意外的是另一件事：在 16-bit TIFF 上， LZW 经常会把文件压得比原始还大。摄影师早就量过这个问题。Jason Odell 的 TIFF 压缩选项速览 和 DarkroomPhotos 的对比测试 给出的结论一致：16-bit 默认选 ZIP ，8-bit 默认选 LZW ，不论选哪个，照片类内容能省下来的体积大致就在 10–20% ，不是 JPEG 那种 70% 的量级。

10–20% 是 Path A 的天花板。想要更激进的体积下降，就得走 Path B 了。

Path A —— 留在 TIFF 里：用 LZW/ZIP 重新打包，配合 Resize

Path A 让文件继续是 TIFF 。无损不变、归档属性不变，跟所有要”扁平 TIFF”的印刷厂的兼容性都不变。你只是把可以削掉的东西削掉：编码方式，以及可选的像素尺寸。

编码这一步只有一个决定要做：

• LZW ：文件是 8-bit 、要送印刷供应商、或者目标是只认 Baseline + LZW 的老式 RIP 。
• ZIP ：文件是 16-bit 、来自 Lightroom 或 Capture One 、或者会留在现代 Mac / Adobe / Affinity 工作流里。

Resize 才是真正的”省字节”那一步。把长宽各砍一半，像素总数就剩 1/4 ；再砍一半就是 1/16 。索尼 A1 导出的 7952 × 5304 缩到 3976 × 2652 ，归档意图完全一样，存储成本只剩四分之一。Zipic 把这两件事合成一遍：在预设里设好目标宽度，resize 和 LZW/ZIP 重打包同步发生。

如果你在意色彩和 HDR ，有两个细节值得知道：

• ICC 色彩档案在 resize 路径上会被强制保留 。你的 ProPhoto 或 AdobeRGB 标记会跟着出去——而你之所以拍 16-bit ，正是为了它。
• HDR gain map 数据存在时也会被保留 。Zipic 检测到 HDR TIFF 时会跳过 resize ，把 gain map 辅助数据原样写到输出——这正是 Apple 的 HDR 显示管线想要的。

Path A 是”文件必须留在 TIFF”时的正确答案。它不是”文件碰巧以 TIFF 形式抵达”时的正确答案。

Path B —— 把 TIFF 转出到 JPEG/WebP/AVIF/HEIC/JXL

绝大多数人遇到的”TIFF 太大”问题，其实在这一节。文件 180 MB ，目的地却是一个网站、一封邮件、一条 Instagram 、一次 CMS 上传、一条 Slack 消息。这些目的地里没有一个在乎”无损 16-bit ProPhoto 归档”。诚实的答案是：别再把 TIFF 寄给不需要 TIFF 的人。

Zipic 接受 TIFF 作为来源，可以转出到下面任意一个：

目标格式	100 MB TIFF 典型输出体积	适用场景
JPEG（Q80）	100 MB → 2–5 MB	通用兼容、社交、邮件
WebP（Q80）	100 MB → 1–3 MB	现代网站、博客主图
AVIF（Q60–70）	100 MB → 0.6–2 MB	现代浏览器上的激进 Web 交付
HEIC（Q80）	100 MB → 1–3 MB	Apple 原生存储、照片图库
JPEG XL（Q80）	100 MB → 1–3 MB	长期 Web 归档、面向未来的母片
PNG（无损）	100 MB → 30–70 MB	仅当同时需要透明 + 无损时才用

这些数字不是宣传——它是 24 MP 16-bit TIFF 在表格里那个质量档位上真实跑出来的范围。JPEG 一行的数据和 DPReview 上摄影师的实测 一致：100 MB 的 TIFF 在高质量下大约落在 10–13 MB ，调到 web 优化质量则能压到 5 MB 以下。

浏览器支持是 Path B 通常获胜的另一个理由。除了 Safari ， 没有任何主流浏览器原生支持在 <img> 标签里渲染 TIFF —— Chrome 和 Firefox 直接弹出下载框，这一点在多份 TIFF 浏览器支持指南 和 OpenSeadragon issue 里都有据可查。按 StatCounter 2026 全球统计 ， Safari 全设备份额约 18.4% ——也就是说，公开网页上嵌一张 TIFF ，对 剩下 ~81% 的访客而言就是一张坏图。

转换本身就是同一次拖拽的一部分。在预设里把 Save Format 设成目标格式，把 TIFF 拖进来，结束。

在 Mac 上用 Zipic 压缩 TIFF 的完整流程

先说一句重要前提： TIFF 压缩在 Zipic 里是 Pro 专属功能 ，跟 ICNS 、AVIF 、JPEG XL 、SVG 、APNG 、PDF 同列。免费版会静默跳过 TIFF 输入——这是诚实的选择：没有办法在免费层”假压一下”还不让用户产生误解。

装好 Zipic Pro 之后，整个流程就三件事：

1. 打开 Compression Settings ，编辑（或复制）一个预设，把 Save Format 设成 TIFF （走 Path A），或者设成 JPEG / WebP / AVIF / HEIC / JXL 任何一个（走 Path B）。 TIFF 的压缩算法（LZW 或 ZIP）也在同一个面板。

2. 把 TIFF 文件拖进主窗口。没有”开始”按钮。Zipic 按当前预设并行处理所有文件。

3. 等它跑完。 ICC 色彩档案自动跟着走， HDR gain map 复制到输出， EXIF / IPTC / XMP 元数据在打开 保留元数据 选项时会被保留——如果文件要送到印刷供应商、图库代理、或博物馆归档，这一项必须开。

就这样。没有”TIFF 质量”滑块，因为底层 CoreGraphics 编码器根本不读这个参数。没有”剥离图层”选项，因为别人的母片不该在压缩工具里被压扁。压缩本身就是它该有的样子：无损、重打包、忠实。

更深入的批量工作流可以看 Mac 批量压缩图片完整教程 。决定走 Path A 还是 Path B 的有损 / 无损取舍，看 有损 vs 无损压缩详解 。

什么时候留 TIFF，什么时候转出

判断比想象的简单。

留 TIFF 的情况：

• 文件是 母片 / 归档 ，可能要重新调色、重新导出、交给另一位修图师。无损完整性就是它存在的全部意义。
• 印刷供应商或印前工作流 明确要 TIFF 。他们大概率指的是 8-bit CMYK 、300 DPI 、扁平 + LZW ，按 PSPrint Photoshop 指南 配置即可。这一节别即兴发挥。
• 文件是 多页扫描归档 ——书页、缩微胶片、政府档案。 TIFF 容器原生支持多页， JPEG 和 WebP 不支持。
• 文件带着 alpha 通道 ，下游合成依赖它，目标是另一个图像编辑应用而不是浏览器。
• 文件来自 CT 、MRI 、科研仪器 ，原始就以 TIFF 输出以保证可追溯性。一旦转码就丢失了证据链。

转出 TIFF 的情况：

• 目的地是 网站、博客、邮件、Slack、社交、CMS ——任何由浏览器或手机渲染的地方。
• 你在发 客户预览或选片样张 ，不是最终交付。
• 你需要 批量发邮件 ，并且要塞进 Gmail 25 MB 附件上限 （MIME 编码会让有效负载翻倍，磁盘上实际可用 ~12.5 MB）。 180 MB 的 TIFF 寄不出去， 1.5 MB 的 JPEG 或 WebP 轻松通过。
• 文件 要上作品集网站 ，并且 Core Web Vitals 是有指标要求的。每个发布渠道对应的预设参数可以参考 摄影师图片优化指南 。

要避免的对称错误是：把不可替代的归档母片转成 JPEG 来”节省空间”，又把网页主图存成 TIFF 来”保证质量”。两边都输。把 Path A 用在那些必须留 TIFF 的文件上；把 Path B 用在其它所有文件上。

用文件夹监控做 TIFF 流水线

预设搭好之后， Zipic 的 文件夹监控 功能就能盯住一个目录，把每个落进去的 TIFF 自动处理掉——扫描工作流里很有用：扫描仪把文件丢进 ~/Scans ，监控自动压缩，免得它把硬盘塞满；修图工作流也一样： Capture One 把 TIFF 输出到交付目录，监控自动跟上。

两个值得搭起来的模式：

• ~/Scans/raw → ~/Scans/archive ：用一个 TIFF-LZW 预设保留归档保真度，再加一个并行的 JPEG 预设产出可立即浏览的副本。
• ~/Deliveries/[client]/tiff → ~/Deliveries/[client]/web ：用一个 WebP-Q80 预设，让每张修图师 TIFF 都有一份 web-ready 的兄弟版本，没人需要手动跑导出。

两套都复用同一套预设机制——监控只是触发器。 文件夹监控配置 配一次，永远不用再管。

为什么”用预览就行”是个陷阱

Mac 上一个常见的假设是 预览 (Preview) 能搞定。理论上它确实能保存带压缩的 TIFF ，但这个选项从 Monterey 12.1 起就坏掉了——当源文件是 TIFF 时，预览的”压缩”下拉菜单在导出时被静默忽略，存出来的文件还是和原文件一样未压缩。 Apple Support 帖子 和多个 DPReview 论坛帖 都有据可查，目前在售 macOS 也没看到官方修复说明。

其它 Mac 默认工具同样指望不上。 sips 能重写 TIFF 但不让你选 LZW 还是 ZIP ； 照片 和 快速预览 干脆走 JPEG 路径重编码，把”保持无损”这件事从根上打掉。 TIFF 比任何其它格式都更需要一个”知道自己在动什么”的工具。

TIFF 压缩 FAQ

能不能让 TIFF 走有损来大幅缩小体积？ 理论上你可以把一份 JPEG 包进 TIFF 容器（JPEG-in-TIFF ， tag value 7），但大多数印前工作流不收，而且这等于把 TIFF 存在的理由抛掉了。如果你需要有损，换容器 ：通过 Path B 转成 JPEG 、WebP 、AVIF 、HEIC 或 JXL 。Zipic 不暴露 JPEG-in-TIFF ，原因正在于此。

为什么质量滑块在 TIFF 上看不出明显效果？ 因为 LZW 和 ZIP 都是 数学意义上无损 的——压根没有任何信息可供”质量参数”去丢弃。某些工具看上去能调”TIFF 质量”，要么是空操作，要么就是悄悄改写成 JPEG-in-TIFF 。

Zipic 里 TIFF 为什么是 Pro 功能？ TIFF 与 ICNS 、AVIF 、JXL 、SVG 、APNG 、PDF 同属 Pro-only 一组。共同的理由是：这些格式要么需要专属编码路径，要么承担生产工作流保证（ICC 、HDR 、元数据、多页），或者两者皆有。 Zipic 免费版覆盖 JPEG 、PNG 、WebP 、HEIC 、GIF ，足够日常用； TIFF 落在生产侧。

Zipic 在压缩 TIFF 时会不会把我的 Photoshop 图层剥掉？ 不会自作主张地”剥”，但会写成一份扁平单图 TIFF ，像素数据、 ICC 档案、（可选）元数据全部保留。如果你的源文件含 Photoshop 图层，压缩后的输出会是扁平等价物——这正是交付和归档需要的，但不是”准备回 Photoshop 继续编辑”想要的。带图层的原始文件请单独留好。

16-bit 印刷母片该选 ZIP 还是 LZW ？ ZIP 。 16-bit 数据上 LZW 通常会让文件变大而不是变小； ZIP 在照片内容上一般能省 10–20% 。唯一选 LZW 的理由是下游 RIP 明确不读 Deflate 。

这套流程在 macOS Tahoe 26 上能用吗？ 能。 Zipic 的 TIFF 路径走的是 CoreGraphics 的 CGImageDestination 配 kCGImagePropertyTIFFCompression ，这是稳定的系统 API 。 ICC 、 HDR gain map 、元数据行为在当前版本上都跟着走。

中文出版与印刷场景的 TIFF 实践

国内的图书出版、商业印刷、报纸印厂、影楼相册定制服务普遍仍把 TIFF 作为母片格式——尤其是中信出版、人民邮电、中国摄影出版社等出版社的画册项目，以及雅昌等高端印刷厂。常见交付要求：

• 画册 / 高端印刷：300 DPI、CMYK 色彩空间（重要：国内 RIP 几乎都默认按 CMYK 解释 TIFF）、ZIP 或 LZW 无损压缩、保留 ICC（中国常见 ISO Coated v2 或 GRACoL）
• 报纸印刷：150-200 DPI、CMYK、可接受 LZW
• 书法 / 国画扫描母片：16-bit RGB、ProPhoto RGB 或 AdobeRGB、ZIP 无损、保留所有元数据
• 影楼定制相册（海马体 / 千佳冲印 / 京东冲印）：JPEG 质量 95+ 即可，不需要 TIFF——印厂会再做内部转换；强行交 TIFF 反而拖慢上传

国内出版社的常见踩坑是色彩空间错位——设计师在 sRGB 屏幕上修图、导出 sRGB TIFF 直接交给印厂，印厂的 RIP 强转 CMYK 后偏色严重。母版用 AdobeRGB 或 ProPhoto RGB + 在 Photoshop 里做 sRGB → CMYK 的”软打样”预览，是行业标准流程。

Zipic 在国内印刷场景的位置：Zipic 不参与色彩空间转换——它的工作只是无损压缩 TIFF（LZW / ZIP）让母片小一点便于上传给印厂。色彩管理仍然要用 Photoshop / Capture One / Helicon Focus。

相关阅读

• Mac 批量压缩图片完整教程
• 有损 vs 无损压缩详解
• 摄影师图片优化指南：压缩不损细节
• 如何为项目选择正确的图片格式
• Mac 上批量转换图片格式（2026 年指南）

延伸阅读：图片格式选择 · 图片压缩基础

---

别再跟扫描仪和修图师丢过来的 180 MB TIFF 较劲了。 下载 Zipic ，把 TIFF 压缩 加进 Mac 工作流。下载即享 7 天完整 Pro 体验。 Zipic Pro 解锁 TIFF 、ICNS 、AVIF 、JXL 、SVG 、APNG 、PDF 压缩，外加无限预设、 Drag to Notch 、文件夹监控。