上一篇测的是「网站已经压过一次」的成品图，ImgZilla 又省下 46.8%。这一篇换到另一个极端：相机和手机直出、从没被任何工具处理过的原图。同样不引用任何行业统计，只放一次真实跑测的结果，附对照方法。
一、这次的测试对象：真正的「原图」
上一篇的样本有个前提——那些图在入库时被网站压过一轮，已经不算生图。这次把前提去掉，测的是相机 / 手机拍完直接导出的 JPEG，没有经过任何压缩工具、没有另存、没有二次编码。
样本规模：32188 张 JPEG，按 16 个 bucket 子目录归档，没有为测试挑选或清洗过。
这批文件的总体积：99.9 GB（约 93 GiB）。
图片规格也很典型——全部是相机 / 手机的标准输出分辨率：
| 分辨率 | 张数 | 占比 |
|---|---|---|
| 4000×3000（12MP） | 19867 | 61.7% |
| 4032×3024（12MP，iPhone） | 3529 | 11.0% |
| 3456×4608（16MP 竖版） | 2631 | 8.2% |
| 其它（3120×4208、4608×3456、2448×3264…） | 6161 | 19.1% |
平均每张 11.5 百万像素、2.96 MB，最大的单张 18.3 MB、30 百万像素。这就是一台手机或相机拍出来、你从没管过的那些照片。
问题是：这种「谁都没碰过」的原图，一个专门的压缩工具能挤出多少？
二、结果：省下 76.8%，99.9 GB 变成 23.1 GB
32188 张图逐一原地压缩，文件名、目录结构、分辨率原样不动：
| 体积 | 相对原始 | |
|---|---|---|
| 相机直出原图 | 99.9 GB | — |
| ImgZilla 压缩后 | 23.1 GB | -76.8% |
一次压缩省下约 76.7 GB，压缩后只剩原来的不到四分之一。 32188 个文件的相对路径、文件名、目录层级，压缩前后完全一致——这是能直接拿真实数据对比出来的。
对照上一篇：
| 测试批次 | 图片来源 | ImgZilla 压缩率 |
|---|---|---|
| 上一篇（4624 张） | 网站已压过一次的成品图 | -46.8% |
| 本篇（32188 张） | 相机 / 手机直出原图 | -76.8% |
结论很直接：越是没被处理过的原图，可挖掘的空间越大。 网站入库时那轮压缩已经吃掉了一部分冗余，剩给 ImgZilla 的是 46.8%；而相机直出的图这部分冗余一点没动过，ImgZilla 能一次拿走 76.8%。
三、为什么相机原图能省这么多
相机和手机在导出 JPEG 时，优先级是「先别丢细节」，不是「文件尽量小」。所以直出的 JPEG 里有大量对画质没有贡献的体积：
- 偏保守的质量参数：直出 JPEG 常用 quality 90–98 的量化表，肉眼早已分辨不出更高质量带来的差别，但字节数差很多。
- 通用的、非最优的熵编码：直出编码用固定的标准霍夫曼表，不为每张图单独计算最优编码，也不做 trellis 量化、不做渐进式扫描优化。
- 一堆附带数据：EXIF、GPS、厂商私有字段、内嵌的整张预览缩略图、色彩配置文件——这些加起来经常是几十上百 KB。
ImgZilla 对 JPEG 做的是视觉无损的重新编码：用更优的编码策略重排熵编码、把量化参数收到肉眼无法分辨的区间、清掉冗余附带数据。像素层面确实有变化，但参数选在几乎看不出差别的位置，所以在「原图」这种冗余充足的素材上，一次就能拿走四分之三。
必须说清楚一个容易被混用的词：「视觉无损」不等于「无损」。无损（像素完全不变）只出现在 PNG（oxipng）和 SVG 上；JPEG、WebP、AVIF、HEIC、GIF 原理上都是有损重编码，只是压缩参数选在了视觉无损的区间。不想凭这句话就信，ImgZilla 内置对比窗口，压缩前后左右分屏、可缩放到实际大小逐像素对照，自己看。
四、拆开看：逐文件压缩比、像素尺寸、极端案例
前面的 76.8% 是整批 32188 张的总体积对比。拆到单文件级别还能看到几件更具体的事。
绝大多数图省下 70%–90%
把 32188 张图逐一按「压缩前字节 → 压缩后字节」配对，按省下的比例分档：
| 省下比例 | 张数 | 占比 |
|---|---|---|
| 90%–100% | 866 | 2.7% |
| 80%–90% | 11375 | 35.3% |
| 70%–80% | 15244 | 47.4% |
| 60%–70% | 3349 | 10.4% |
| 50%–60% | 398 | 1.2% |
| 低于 50% | 956 | 3.0% |
82.7% 的照片省下了 70%–90%。 逐文件压缩比的算术平均是省 76.6%，和按总字节量算出的 76.8% 几乎重合——说明这批文件里压得多和压得少的，在体积权重上分布得比较均匀，没有被少数超大文件带偏。
按分位数看：一半以上的照片省下 77% 以上；即使是压缩收益最差的 10%，也省下了约 68%；只有大约 1% 的照片（p99）省下的比例低于 40%。
像素尺寸：一个像素没变
统计全部 32188 张图的分辨率变化：dimensions_changed 全为 false——100% 保持原分辨率。ImgZilla 不缩放、不裁剪，省下的 76.7 GB 全部来自重新编码，不是从像素上抠出来的。这是「原地压缩」定义里容易被忽略的一半：不只是文件名和路径不变，分辨率也完全不动。
几个极端案例
| 类型 | 原始 | 压缩后 | 省下 |
|---|---|---|---|
| 压缩比最高 | 3.55 MB（4000×3000） | 100 KB | 97.2% |
| 单张省下最多 | 17.90 MB（4000×3000） | 1.13 MB | 16.8 MB |
| 收益最差 | 70 KB（1242×1242） | 68.8 KB | 2.1% |
压缩比最高的那批（省 95% 以上）通常是相机用了极高质量参数、又带满元数据的图；收益最差的是本来就很小、早被处理过的图。平均每张省下 2.38 MB。
五、换算成每月账单：这 76.8% 值多少钱
体积省了，落到账单上才有感觉。下面不引用任何「压缩提升转化率」之类的统计，只做一件事：拿实测出来的 76.8%，乘以几家云服务商当前公开报价，做纯算术推算。
存储费节省 = 省下的体积（GB） × 单价（元或美元 / GB / 月）
流出流量费节省 = 省下的体积（GB） × 当月下载次数 × 单价（元或美元 / GB）
存储费
| 图库原始大小 | 省下体积 | 阿里云 OSS 标准 ¥0.09/GB/月 |
AWS S3 Standard $0.023/GB/月 |
Google Cloud Storage $0.020/GB/月 |
Cloudflare R2 $0.015/GB/月 |
|---|---|---|---|---|---|
| 10 GB | 7.68 GB | ¥0.69/月 | $0.18/月 | $0.15/月 | $0.12/月 |
| 100 GB | 76.8 GB | ¥6.91/月 | $1.77/月 | $1.54/月 | $1.15/月 |
| 1 TB | 786 GB | ¥70.8/月 | $18.1/月 | $15.7/月 | $11.8/月 |
| 本次实测这批（99.9 GB） | 76.7 GB | ¥6.90/月 | $1.76/月 | $1.53/月 | $1.15/月 |
这是按月重复扣的费用，压一次，此后每个月都按新体积计费——一次性投入、长期兑现。
流量费：真正的大头
流量费是体积 × 下载次数的乘积，图片被访问得越多，压缩收益越大。举例：一个 100 GB 的图库，当月通过 CDN 产生 500 GB 下行流量（相当于整库被完整下载约 5 次），流量随体积同比 -76.8%：
| CDN 出口流量报价（首档价） | 压缩前月流量费 | 压缩后 | 每月省 | 一年省 |
|---|---|---|---|---|
| 阿里云 CDN 国内（¥0.15/GB） | ¥75.0 | ¥17.4 | ¥57.6 | ¥691 |
| AWS CloudFront 亚太区（$0.12/GB） | $60.0 | $13.9 | $46.1 | $553 |
| Google Cloud CDN 北美/欧洲（$0.08/GB） | $40.0 | $9.3 | $30.7 | $369 |
取的都是各家最低阶梯价，实际阶梯价通常更高，账单越大压缩省下的绝对值越可观。Cloudflare R2 是例外：出口流量本身 $0，收益几乎全部体现在存储费上。
以上单价为 2026 年各平台公开报价的整理，实际价格按地域、账户折扣、阶梯档位浮动，请以官网当前价格为准；下载次数为示例假设，请替换成自己账单里的真实数字。
六、本地场景：搬这批数据省多少等待时间
体积砍掉 76.8%，传输时间基本同比例缩短——这条不需要云账单也成立，直接体现在拷贝、备份的等待时间上。
- USB3 移动机械硬盘：持续吞吐取 120 MB/s。
- USB3 移动固态硬盘：取 450 MB/s。
- 千兆有线网络：扣掉协议开销取 105 MB/s。
| 场景 | 省下体积 | USB3 机械硬盘 | USB3 固态硬盘 | 千兆网络 |
|---|---|---|---|---|
| 本次实测这批图 | 76.7 GB | ≈11 分钟 | ≈2.9 分钟 | ≈12.5 分钟 |
| 10 GB 图库 | 7.68 GB | ≈66 秒 | ≈17 秒 | ≈75 秒 |
| 100 GB 图库 | 76.8 GB | ≈11 分钟 | ≈2.9 分钟 | ≈12.5 分钟 |
| 1 TB 图库 | 786 GB | ≈112 分钟 | ≈30 分钟 | ≈128 分钟 |
和存储费一样，这是一次性投入、长期兑现：拷进拷出移动硬盘、同步 NAS、跑 Time Machine、换新机迁移、传给同事——只要还在搬这批数据，每一次都按这个比例省时间。
七、如果压缩发生在用户上传之前
前面算的是「图存下来之后」的账。还有一段路更值得算：用户按下「上传」到进度条走完的这段时间，走的是用户自己的上行带宽，而上行几乎永远是整条链路里最慢的一环。相机直出的原图单张几 MB，比上一篇那种「网站已压过、平均 299 KB」的成品图大一个数量级，这段时间的差别也就明显得多。
以本批实测的单张平均体积算：相机原图平均 2.96 MB，ImgZilla 压缩后平均 0.69 MB，每张省下约 2.27 MB。
| 上传带宽（公开测速的典型区间，仅供参考） | 单张 2.96MB→0.69MB |
上传 50 张相册 ≈148MB→34MB |
上传本批全部 32188 张 99.9GB→23.1GB |
|---|---|---|---|
| 移动网络（4G/5G 综合，取 30 Mbps） | 省约 0.6 秒 | 省约 30 秒 | 省约 5.7 小时 |
| 常见家庭宽带上行（取 25 Mbps） | 省约 0.7 秒 | 省约 36 秒 | 省约 6.8 小时 |
| 千兆对称宽带上行（1000 Mbps） | 省约 0.02 秒 | 省约 0.9 秒 | 省约 10 分钟 |
单张 0.6 秒还是不太有感，但一次上传一整本相册、或批量导入几百张相机原图时，省下的分钟数是能明确感知的——尤其对上行本来就慢的移动网络用户。
区间数字来自国内公开测速统计，实际速度受运营商、地区、设备、网络拥塞影响很大，仅作数量级参考。
八、数据与测试说明
- 样本范围：本文数据来自这一批 32188 张相机 / 手机直出 JPEG 的实测，反映的是这批样本的结果，不等于「ImgZilla 平均能压 76.8%」。不同相机、不同机型、结果都会不一样；已被精细优化过的图，可挖掘的空间会明显更小。
- 样本选取：整批文件未做任何筛选或清洗，按原有的 16 个子目录整体压缩，不存在挑选有利样本的情况。
- 与上一篇的可比性：上一篇 46.8%、这一篇 76.8%，差别几乎全部来自素材是否被压过。多数图库会落在这两个数字之间——入库做过压缩的更接近 46.8%，用户首次上传的生图更接近 76.8%。
- 统计口径：文中的 76.8% 为「总节省字节 ÷ 总原始字节」；逐文件压缩比的算术平均为 76.6%，中位数 77.3%，两种口径均已在正文中列出。体积单位按 1 GB = 10⁹ 字节换算。
- 压缩参数：参数固定，界面上没有质量滑块。这是设计取舍——每种格式的参数已调校到视觉无损区间的平衡点。习惯自己手动调参的用户，这一点需要留意。
- 运行环境：全程在本机完成，图片不会离开这台 Mac，不需要联网（App Store 购买校验除外）。
价格参考来源（2026 年公开报价，具体以各平台官网实时价格为准）：AWS S3 Pricing、阿里云 OSS 收费标准、Google Cloud Storage Pricing、Cloudflare R2 Pricing、阿里云 CDN 收费标准、AWS CloudFront Pricing、Google Cloud CDN Pricing。
想亲自验证？ 直接从 Mac App Store 下载 ImgZilla，用自己网站上已处理过的几张图实测一遍，再决定是否继续压缩其它。
Mac App Store： https://apps.apple.com/app/apple-store/id6749323539?pt=127227004&ct=v2&mt=8
了解更多： https://imagetool.app/ImgZilla
系统要求：macOS 12.3 或更高版本。