译介 | 图像编码器测评 | jpegli

作者：Gianni R

原标题：Mini Image Codec Comparison; jpegli

原文链接：giannirosato.com/blog/post/j...

编译：谢林中路

译注：日前，谷歌开源发布了Jpegli编码库，一个后向兼容JPEG 92的编码格式。不过，既然Jpegli本身就是JPEG XL技术演进的产物，很难理解为什么Chrome仍不支持JPEG XL，是否有点精神分裂了。当然，谷歌本身就是JPEG XL的主要贡献组织，这无疑更令人呃呃。（如何解释这种精分？或许是因为视频编码标准团队在Chrome团队中更有影响力，他们更愿意推动AVIF和WebP？）

无论如何，顺手翻译一篇jpegli的性能测评。不代表译者观点。(测评有很多，顺手是一个原因，另一个原因是这里参数比较详细、而且主要是提到AVIF并行化的问题，记跟进TODO)

缘由

JPEG是一个非常简洁的编解码器。多年来，它为我们提供了非常好的服务。JPEG巧妙的简单设计将图像划分为8x8像素块，将色度（颜色）与亮度（亮度）分离到YCbCr色彩空间（您也可以使用RGB）、应用DCT、量化DCT系数，并将数据传递给解码器，使JPEG图像现在非常易于读写。它们看起来也不错。

事实上，随着编码实现（以某种方式）不断改进，它们看起来越来越好：

• MozJPEG相对于libjpeg-turbo和较旧的实现提高了质量，特别是在中低保真度下；jpegli 有望进一步改进 MozJPEG，这可能是全面的改进。

• JPEG 还具有许多现代编解码器所不具备的非常有用的功能，例如支持渐进式解码，它允许在传输图像数据时发送部分图像。

• Blurhashes 非常受欢迎，因为它们能够在整个图像之前发送一些数据，而渐进式解码进一步增强了这一点。WebP、HEIC 和 AVIF 不支持渐进式解码*，但 JPEG-XL 支持。

*如果你发送了一个含有单帧超低质量帧的动画AVIF，该帧在实际图像之前加载，那么AVIF在某种程度上支持渐进式解码。你也可以使用其他技巧，更多信息在这篇Autocompressor博客文章中有概述。

• 除了这些功能之外，当 MozJPEG 发布时，JPEG 还在编码效率方面声称能与 WebP 竞争。这与 WebP 比 JPEG 小 25%-34% 的说法相反（出处是谷歌的指出，"我们观察到，在等效的SSIM索引下，与JPEG文件大小相比，平均WebP文件大小要小25%-34%"，这很重要，因为SSIM在这一点上是一个相当过时的指标，并且在很大程度上并不表示感知质量。他们还测试了 libjpeg，而不是 mozjpeg）

jpegli 会不会如此高效，以至于 WebP 完全被一个近 20 年前的编解码器所超越？

Jpegli 的工作原理

Jpegli的收益很大程度上归功于基于JPEG-XL使用的启发式方法的更好的自适应量化。像 Guetzli 这样的项目通过类似的方式实现了更好的 JPEG 压缩，但使用起来真的很慢。Guetzli 的自述文件中概述了它的速度：

Guetzli uses a significant amount of CPU time. You should count on using about 1 minute of CPU per 1 MPix of input image.

Guetzli 占用了大量的 CPU 时间。您应该指望每 1 MPix 输入图像使用大约 1 分钟的 CPU。

另一个聪明的 jpegli 技巧是使用 XYB 色彩空间，与 RGB 相比，它在感知上更符合人类的视觉系统。我们今天还没有对此进行测试，因为 SSIMULACRA2.1 不理解它在给定 XYB JPEG 时所看到的内容（即使正确转码为 PNG，也会有某种有害的颜色偏移），但 JPEG-XL 默认使用 XYB 色彩空间进行有损图像编码，结果显示其编码效率是惊人的。

jpegli 处理 JPEG 图像中 XYB 颜色的方式是应用将现有 JPEG 颜色通道映射到 XYB 的 ICC 颜色配置文件。这实际上有可能增加图像的位深度------这将来可能允许 10 位 JPEG。我很高兴看到 XYB JPEG 通过 jpegli 继续改进，但现在我们只打算使用 libjxl 附带 cjpegli 的二进制文件来测试一些摄影图像。

测评

以下是我用于此测试的编码器：

• cjpegli 来自libjxl，以 4：4：4、4：2：2 和 4：2：0 色度子采样模式
• mozjpeg mozjpeg version 4.1.1 (build 20230217)
• cwebp cwebp 1.3.0 | libsharpyuv: 0.2.0
• cjxl via cjxl v0.9.0 e2fe7bad [AVX2]
• avifenc AOM-AV1-Lavish，最新的 Git分支（Endless_Merging）

以下是它们的编码参数：

• cjpegli input -q [quality] --chroma_subsampling=[444/422/420] output.jpg
• cjpeg -q [quality] input > [output.jpg]
• cwebp -m 6 -q [quality] input -o output.webp
• cjxl input output.jxl -q [quality] -e 8
• avifenc -c aom -s 4 -j 8 -d 10 -y 444 --min 1 --max 63 -a end-usage=q -a cq-level=[quality] -a tune=ssim [input] [output.avif]

以下是测试的四张摄影图像：

使用上述参数对每个方案进行的速度基准测试。参数的修改如上。使用hyperfine进行基准测试，在测试库中的第一张图片上测试：

hyperfine --warmup 2 --runs 20 "command"
inxi -v CPU: 16-core (8-mt/8-st) 13th Gen Intel Core i7-13700K (-MST AMCP-) speed/min/max: 1386/800/5400 MHz Kernel: 6.3.7-zen1-1-zen x86_64 Up: 29m Mem: 5633.8/31868.7 MiB (17.7%) Storage: 6.83 TiB (20.4% used) Procs: 520 Shell: Zsh inxi: 3.3.27

• cjpegli -q 90, --chroma_subsampling=444: 156.1 kB

Time (mean ± σ): 80.1 ms ± 0.7 ms [User: 75.7 ms, System: 4.2 ms] Range (min ... max): 79.1 ms ... 81.4 ms 20 runs

• cjpegli -q 90, --chroma_subsampling=422: 145.4 kB

Time (mean ± σ): 74.3 ms ± 0.7 ms [User: 70.2 ms, System: 3.9 ms] Range (min ... max): 73.2 ms ... 76.0 ms 20 runs

• cjpegli -q 90, --chroma_subsampling=420: 132.2 kB

Time (mean ± σ): 70.6 ms ± 0.5 ms [User: 66.3 ms, System: 4.1 ms] Range (min ... max): 69.8 ms ... 71.5 ms 20 runs

• mozjpeg -q 86: 154.8 kB

Time (mean ± σ): 105.0 ms ± 0.9 ms [User: 101.6 ms, System: 3.0 ms] Range (min ... max): 103.5 ms ... 107.6 ms 20 runs

• cwebp -q 90: 130.7 kB

Time (mean ± σ): 194.4 ms ± 1.4 ms [User: 190.5 ms, System: 3.6 ms] Range (min ... max): 191.8 ms ... 197.1 ms 20 runs

• cjxl -q 92: 134.0 kB

Time (mean ± σ): 768.1 ms ± 7.0 ms [User: 1068.8 ms, System: 398.4 ms] Range (min ... max): 758.6 ms ... 784.1 ms 20 runs

• avifenc cq-level=11: 155.5 kB

Time (mean ± σ): 1.500 s ± 0.008 s [User: 3.670 s, System: 0.016 s] Range (min ... max): 1.493 s ... 1.529 s 20 runs

• avifenc cq-level=11 -j all: 155.5 kB

Time (mean ± σ): 1.571 s ± 0.132 s [User: 3.778 s, System: 0.019 s] Range (min ... max): 1.495 s ... 1.975 s 20 runs

使用所有可用线程的avifenc通常会产生略微糟糕的结果，且Hyperfine每次运行时都会抛出一个错误，提示某些结果似乎是异常值。这就是为什么我在质量基准测试中将工作线程数降低至8的原因。这种异常行为很有趣，因为它突显了avifenc在扩展性上的问题，这源于AVIF图像格式的问题。

我会猜测，这种扩展性问题是因为AVIF使用了某些帧内编码技术，比如方向预测，使得数据在块之间共享，理论上可以提高编码效率，但实际上却减少了并行化能力并加剧了生成损失。如果我没记错的话，JPEG-XL特意避免使用这类帧内编码技术，以保证有效地并行化（并提升对生成损失的抵抗力）。

下面是每张图像的测试结果！值得一提的是，在我的分析中，我更喜欢看我认为最有用的 60-70+ 范围。其他人可能不同意，所以这里只事个人意见。

图片1

第一张图这里显然更偏爱jpegli（而非mozjpeg）在60-80的中高保真度范围内，jpegli的三种色度子采样模式和WebP可以说是不分上下，而mozjpeg则落后了。值得注意的是，这里WebP的总体质量上限较低，最高得分约为90。

个人排名：

1. JXL
2. AVIF
3. jpegli 4:2:0
4. WebP
5. jpegli 4:4:4
6. jpegli 4:2:2
7. mozjpeg

图片2

第二张图片中简单的线条和大面积的颜色让我联想到非摄影图像，因此更适合AVIF与WebP，它们分别源自于视频编码器（AV1和VP8）。虽然看起来4:4:4的jpegli在得分高于95时表现良好，但中高保真度范围却被mozjpeg主导。这里WebP的质量上限非常低，似乎无法达到90的得分（而SSIMULACRA2.1开始认为图像在感知上是无损的就是从90分开始）

个人排名：

1. AVIF
2. JXL
3. WebP
4. mozjpeg
5. jpegli 4:4:4
6. jpegli 4:2:0
7. jpegli 4:2:2

图片3

第三张图片看起来在jpegli、mozjpeg和webp之间一直很难区分优劣，而AVIF和JXL则一直领先。4:4:4的jpegli整个范围内表现稳定，而mozjpeg在较高保真度下开始下降，遗憾的是WebP在接近90分的高峰前就达到了其质量上限，尽管在其他质量范围内仍保持着较强的编码效率。】

个人排名：

1. JXL
2. AVIF
3. jpegli 4:4:4
4. WebP
5. mozjpeg
6. jpegli 4:2:0
7. jpegli 4:2:2

图片4

第四张图片差距最小。我再次感到失望的是，在大约83分以上的地方，WebP被4:4:4的jpegli超越，并且似乎无法得分超过90，而4:4:4的jpegli和mozjpeg则可以轻松上升到大约95分。这个额外的增益对于摄影和网页传输之外的许多用例很重要，这也是为什么我认为"编码器能够在整个质量谱中表现出色而不会过早遇到障碍"很重要。这里我们看到AVIF和JXL的行为与我的图像编码器比较博客文章中的描述相似，AVIF在低保真度性能上表现强劲，而JXL则在高保真度结果方面更胜一筹。

个人排名：

1. JXL
2. AVIF
3. jpegli 4:4:4
4. WebP
5. mozjpeg
6. jpegli 4:2:0
7. jpegli 4:2:2

延申

首先，如果您不了解色度子采样是什么，我强烈推荐您查看Master of Zen的解释。这是一个更详细的解释，并且全面覆盖了色度子采样的效果。

值得指出的是，我并没有尝试每一个mozjpeg调整参数，而我见过SSIM和MS-SSIM调参设置在压缩摄影图像时可以工作得很好。我也没有测试mozjpeg提供的每一种色度子采样模式并允许mozjpeg自动子采样色度------这种自动选择在理论上赋予它相比每个单独的jpegli色度子采样模式的优势，但不会像这里的jpegli一样允许编码器显示其全面的能力。最后，我不会因此而认为mozjpeg输了------它显然在任何情况下都不过时，而且唯一明显输掉的情景是第一张图像测试。整体平均和三张图像平均的结果都有力地支持了mozjpeg的综合表现。

虽然仅靠四张图像无法推断出关于这些编码器的任何实质性结论，但我们确实可以看到不同编码器之间的明显差异。特别是，我认为"WebP比JPEG明显更高效"的观点几乎完全被像mozjpeg和现在的jpegli这样的现代JPEG编码器所否定。特别是在网络之外的领域，WebP在需要更高保真度的地方显得尤其薄弱。

从我对高保真度的个人偏好退一步来看，jpegli 4:2:0在目标小于50-60时能够如此一贯地表现出色令人印象深刻。而这通常是WebP的领域（暂时忽略AVIF和JXL），与JPEG相比，4:2:0的jpegli在所有图像上都比mozjpeg更接近WebP，除了第二张图像之外。而4:2:2的jpegli似乎没有多大用处。

使用建议

应该使用它吗？ 我会说，这取决于您的情况：

• 不能使用AVIF或JXL
• 不能使用WebP，或者如果可以使用，但它压缩得更糟
• 偏好渐进式解码且不能使用JXL
• 至少已经与mozjpeg进行了A/B测试，我也建议测试其他的cjpegli色度子采样模式
• 用你的眼睛看结果更满意，这比指标更重要

我使用指标是因为在这里表达我的视觉偏好、并基于它们推导出客观数据会非常困难。您也可尽可能进行自己的主观测试，并训练自己寻找并识别图像处理中的伪影；蚊噪声、振铃效应、方块效应和带状效应等常见伪影。

现在苹果宣布对JXL的支持，希望网络行业的潮流会向新的图像编码转变。但愿我们将看到惊人的市场渗透率，以至于我们不再需要使用JPEG。但现在，这还不是现实，JPEG的兼容性仍然无与伦比；考虑到这些情况，我建议当然是尽可能使用JXL。当你必须使用JPEG时，利用众多现有的JPEG编码工具对你来说将是明智的选择。

感谢你的阅读！