实测：HEIC 转 JPG，质量参数怎么选
转换页上的「JPG 质量」滑块从 10% 到 100%，到底该停在哪一格？我们拿两张真实照片，走站点自己的转换管线跑了 5 个档位，把体积、峰值信噪比和平均色差都量了出来。下面所有数字都是实测结果，复现脚本在仓库里。
测试方法
为了让结果能对应到真实使用场景，整个流程走的是站点自己的转换管线，没有任何模拟：用无头浏览器打开转换页，把 .heic 交给它，拖动质量滑块，点重新转换，再取回真实输出的文件。
- 素材：两张公开发布的照片（Unsplash 授权，经 picsum.photos 获取），各 3200×2400 像素。
- HEIC 样本：先用 HEVC 编码成 .heic（质量 90），作为「iPhone 原图」的替身。
- 转换档位：JPG 质量 60% / 70% / 80% / 90% / 100%，共 5 档，输出尺寸保持原样。
- 体积：直接取输出文件的字节数。
- 画质：以 HEIC 解码后的像素为基准算 PSNR（峰值信噪比）与平均色差。
- 环境：Chrome 无头模式，断网状态本地打开页面；参考解码采用 libheif。
复现用的三个脚本都放在 tools/testkit/ 下（bench_make_heic.py / bench_run_quality.js / bench_report.py），换你自己的照片重跑一遍就能得到同样的表。
体积：每提一档涨多少
| JPG 质量 | 样本 A 体积 | 样本 A 相对 HEIC | 样本 B 体积 | 样本 B 相对 HEIC |
|---|---|---|---|---|
| 60% | 516.4 KB | 33% | 610.9 KB | 28% |
| 70% | 569.3 KB | 36% | 683.1 KB | 31% |
| 80% | 620.1 KB | 40% | 740.2 KB | 34% |
| 90% | 718.5 KB | 46% | 866.6 KB | 39% |
| 100% | 2265.1 KB | 144% | 2961.5 KB | 134% |
两个样本的走向完全一致，有两点值得注意：
- 60% 到 90% 之间是平缓区 —— 体积从 516 KB 涨到 718 KB，只多了约 39%。这一段是「加一点体积换一点画质」的正常交换。
- 90% 到 100% 是断崖 —— 体积直接涨到 3.3 倍。因为质量拉到 1.0 时，浏览器会把参数映射到编码器的最高档，量化步长骤降，压缩几乎不再发生。
画质：PSNR 怎么说
| JPG 质量 | 样本 A PSNR | 样本 B PSNR | 平均色差 | 差异超过 2 色阶的像素 |
|---|---|---|---|---|
| 60% | 41.8 dB | 39.2 dB | 1.40 / 1.76 | 9.7% / 14.3% |
| 70% | 45.7 dB | 44.3 dB | 0.81 / 0.94 | 2.0% / 4.2% |
| 80% | 47.2 dB | 45.7 dB | 0.60 / 0.69 | 1.0% / 3.2% |
| 90% | 49.3 dB | 47.7 dB | 0.41 / 0.51 | 0.09% / 1.3% |
| 100% | 59.3 dB | 57.6 dB | 0.07 / 0.10 | 0.00% / 0.00% |
这里顺带验证了一件事：100% 档的 PSNR 是 59.3 dB，水平很高。这说明浏览器管线解码出的像素与 Python 侧的 libheif 参考解码高度一致 —— 两套实现的色彩管理没有引入偏差，上面这一列数字可以放心当作「相对原图的真实损失」来看。
这些数字怎么读
PSNR 是峰值信噪比，数值越高越接近原图。作为参考线：
- 45 dB 以上 —— 正常观看距离下看不出任何差异。
- 40~45 dB —— 放到 100% 放大才可能看出极轻微的差别。
- 35~40 dB —— 仔细看能发现块状痕迹，尤其是平滑渐变区域。
- 35 dB 以下 —— 明显可见，基本不能用于需要留存的照片。
比 PSNR 更贴近肉眼的是最后一列「差异超过 2 个色阶的像素占比」。两个色阶的差别，人眼在绝大多数情况下察觉不到，所以这个比例越低越好：90% 档时样本 A 只有 0.09%，而 60% 档接近 10%。
结论与建议
| 用途 | 建议质量 | 理由 |
|---|---|---|
| 日常使用（默认） | 90% | 48~49 dB，体积约为最高档的三分之一。默认值的设定是合理的 |
| 网页配图、发朋友圈 | 80% | 再省约 15% 体积，46~47 dB 依然在「看不出来」的区间 |
| 体积优先、能接受轻微损失 | 70% | 45 dB 左右，是肉眼可接受的边界，再往下就开始掉得明显 |
| 不需要人眼友好 | 60% 及以下 | 接近 10% 的像素有明显差异，不建议用于要留存的照片 |
| — | 100% | 不推荐：体积涨 3.3 倍换取约 10 dB，而这段区间本来就已经在看不出差异的范围里了 |
还有一条比调质量更划算的省体积办法：先缩尺寸。像素数量按面积走，最长边从 3200 缩到 1600 会让像素数变成四分之一，体积也大致按这个比例降 —— 而质量从 90% 降到 60% 只能省一半左右，却要付出可见的画质代价。转换页里的「输出尺寸」选项就是做这件事的。
一个不太直观的发现：这两个样本转出的 JPG 反而比源 HEIC 小（90% 档约为 HEIC 的 39%~46%）。原因是素材本身已经是被 JPEG 压过一次的照片，HEIC 只是把原有的压缩痕迹高保真地存了下来。HEIC 的体积优势来自「从原始像素开始编码」的场景 —— 也就是相机直出的时候。对已经压过的图片重新编码，这个优势并不成立。
引用这份数据
本页所有数字都是用仓库里 tools/testkit/ 的脚本实测跑出来的，不是估算值。你可以自由引用，注明出处并链回本页即可。
引用格式
HEIC 转 JPG 质量参数实测（2026-10-14）。HEIC 转 JPG，https://heic.xunidd.com/guide/benchmark/数据表（Markdown）
| JPG 质量 | 样本 A 体积 | 样本 A PSNR | 样本 B 体积 | 样本 B PSNR |
| --- | --- | --- | --- | --- |
| 60% | 516.4 KB | 41.8 dB | 610.9 KB | 39.2 dB |
| 70% | 569.3 KB | 45.7 dB | 683.1 KB | 44.3 dB |
| 80% | 620.1 KB | 47.2 dB | 740.2 KB | 45.7 dB |
| 90% | 718.5 KB | 49.3 dB | 866.6 KB | 47.7 dB |
| 100% | 2265.1 KB | 59.3 dB | 2961.5 KB | 57.6 dB |复现方式
三个脚本都在仓库的 tools/testkit/ 下，按 bench_make_heic.py → bench_run_quality.js → bench_report.py 的顺序跑：第一段把照片转成 HEIC 并生成参考 PNG，第二段用无头浏览器打开真实转换页逐档转换、取回产物，第三段算出 PSNR、平均色差与差分像素占比。bench_report.py 另有 --selftest 开关，用固定输入对拍 PSNR 的计算语义，防止指标算法日后被改坏。
使用条件：署名 + 链接即可引用，无需事先授权。样本是真实拍摄的照片，用来代表 iPhone 直出的 HEIC 画面，所以绝对数值会随拍摄场景的纹理复杂度变化 —— 这正是样本 A 与样本 B 之间出现系统性差异的原因（纹理更密集的那张损失更明显）。