JPEG XL 在 Web 图像编码中的困境与重新审视:技术实力与平台现实的博弈
探讨 JPEG XL 为何在主流浏览器中未能立足,其技术优势与 Web 实际需求之间的差距,以及 AVIF、WebP 等竞争格式的崛起如何重塑图像压缩生态。
在图像压缩技术日新月异的今天,格式的选择往往不仅仅取决于压缩效率的高低,更受浏览器厂商策略、生态兼容性以及开发者实际工作流的深层影响。JPEG XL 曾被视为 JPEG 的 definitive upgrade,被寄予厚望为下一代 Web 图像标准,然而在 2023 年被 Chrome 拒之门外后,其命运便在业内引发了广泛的讨论与反思。本文将从技术细节、性能表现、生态兼容性以及未来发展等多个维度,客观复盘 JPEG XL 的案例,分析其为何难以在 Web 领域占据一席之地,同时也审视其在 Web 外的潜在价值。JPEG XL 的技术规格在纸面上无疑非常印象深刻。该格式支持高达 4096 个通道、任意色深、渐进式解码以及对 JPEG 重编码的友好支持等功能。其背后的编码理念旨在在无损和有损压缩之间实现平滑过渡,并承诺在相同视觉质量下实现比 JPEG 更小的文件体积,或在相同体积下获得更高的图像保真度。
正因为这些看似无可挑剔的规格,才让 JPEG XL 在 2022 年左右获得了包括 Cloudinary、Google 以及多家媒体在内的广泛关注。然而,技术的优秀并不等同于平台的成功,特别是在 Web 这样一个对加载速度、浏览器原生支持以及生态协同有着极高要求的环境中。从 lossy 压缩效率的角度来看,JPEG XL 曾主张其参考编码器具备更强的感知优化能力。然而,随着 AV1 相关技术的成熟以及 AVIF 格式在业界的快速普及,这一论点已不再站得住脚。现代编码器在感知优化上的投入已不亚于 JPEG XL,SVT-AV1 等编码器也引入了基于主观人类试验的调谐模式,在相同码率下的视觉质量 already 逼近甚至超越了 JPEG XL 的表现。客观指标如 CVVDP、MS-SSIM 以及 SSIMULACRA2 的对比分析显示,现代编码器在感知指标上的优势并不小,对于 AVIF 而言,其基于感知的调优仅比纯指标优化低几个点,这已经足以在实际应用中转化为明显的视觉改善。
在压缩工具的选择上,JPEG XL 与 WebP、AVIF 相比存在明显的差异。基于块的预测模式是很多现代编码器用来减少冗余数据的关键手段,WebP 等格式允许通过周围数据预测块像素、减去实际像素后再进行频率变换。这种方向性预测在边缘保持方面表现出色,而 JPEG XL 在这方面的表现相对较弱。JXL 的规范中并未包含传统的去块滤波器(Deblocking Loop Filter,DLF),而是提供了 gaborish 以及 EPF(边缘保持滤波器)等工具,它们虽与 AV1 的 Loop Restoration 以及 CDEF 有一定关联,但并无法完全替代 DLF 的平滑效果。这意味着在某些图像内容下,JPEG XL 仍可能出现马赛克伪影,而这类问题在配备 DLF 的编码器中往往能得到更好的抑制。此外,JPEG XL 的颜色空间设计 XYB 也并非万能钥匙。
虽然理论上基于人类视觉特性的色彩表示应该能带来效率提升,但实际上 libjxl 目前仍依赖对 B 通道的激进量化,这导致了色彩保真度的妥协。新一代 JXL 编码器开发者必须显式地在解码后补偿这一问题,这不仅增加了实现的复杂度,也在一定程度上抵消了原本承诺的压缩优势。对于非摄影类图像 - - 如插图、图表、包含锐利边缘的内容 - - JPEG XL 的表现更是受到了限制。建议使用拼图模式来提升可表达性,但相较于 AV1 的 Intra Block Copy,拼图的编码成本更高,需要处理图层、混合等额外概念,且在比特流层面的开销不容忽视。只有当重复区域足够大或被重复使用很多次时,这种开销才能被抵消。解码性能是 JPEG XL 面临的另一个关键挑战。
虽然其规范极其灵活,支持高通道数、高色深以及渐进式渲染等特性,但在 Web 实际场景中,这些功能的实用性受到限制。大多数 Web 图像仅需 4 个通道(RGB/YUV 加 Alpha),合理的色深(10-bit 已足够支持 HDR),以及快速加载能力。关于渐进式渲染,AVIF 已在 libavif 中实现了该功能,用户可以在全图加载前先看到低保真的预览。相比之下,JPEG XL 的渐进式解码在浏览器中的表现则不够理想,即便在 Safari 中原生支持 JXL,其渐进式解码也并未被广泛利用,反而需要通过 Polyfill 实现,这在性能和实现上都增加了不必要的负担。JPEG 重编码的功能常被引用为 JPEG XL 的一大优势,宣称相比原始 JPEG 可节省约 20% 的空间。然而,这种收益并非"免费"用户付出的代价在于解码时间 - - 重编码后的 JPEG XL 图像解码时间长约 33%。
在现代消费级设备性能日益强大的背景下,这种时间开销在某些场景下或许可以接受,但若将其作为默认方案,尤其是在移动端或低端设备上,解码延迟依然是一个不容忽视的因素。更有趣的是,在公开的对比测试中,即使是体积稍大的 WebP 格式,其解码速度也比 jxl-rs 快了十倍以上。这暴露了一个现实问题:JPEG XL 的编码能力虽强,但其解码效率在当前的硬件与软件生态中并不占优。更令人警惕的是,利用 JPEG XL 的编码灵活性,可以精心制作一些恶意图像,这些图像在解码过程中会执行复杂的计算,消耗大量的 CPU 资源。例如有一个特制的 JXL 图像(需谨慎打开)在 M5 Pro 设备上的 Rust 解码器上耗时 17.43 秒的用户时间,而该图像体积仅 1,918 字节。这类"JXL-bomb"式的攻击手段,在低端设备上可能导致严重的性能阻塞。
由于 Safari 原生支持 JPEG XL,攻击者甚至可以在网页上投放几十张此类图片,轻易拖慢 Apple 设备的响应速度。这也反过来提醒了浏览器厂商在引入新编码格式时必须权衡的安全性与性能权衡。从生态角度审视,Web 图像压缩的格式演进并非单纯的技术选型问题。WebP 的引入曾因兼容性和工具链原因在早期遭遇采用阻力,但凭借 Google 的背书以及渐进式的浏览器支持,如今已成为许多场景的默认选择。AVIF 随着 AV1 视频编码器的成熟,逐渐在视觉质量和压缩效率之间取得了平衡,成为目前公认的下一代 Web 图像格式。其背后拥有庞大的开发者社区、成熟的解码库以及浏览器厂商的广泛协作。
相比之下,JPEG XL 虽然技术实力不俗,却错过了与 AV1 同步进入主流浏览器的机会。2023 年 Chrome 拒绝 JPEG XL 的决定,虽然在当时引起了不少争议,但从长远看,这或许是一次基于平台稳定性与生态兼容性的务实抉择。作者在文中多次表达了对 JPEG XL 技术的尊重,并承认其作者 Jon Sneyers 与 Jyrki Alakuijala 在公开形象、技术深度上的出色表现。但他同时也明确指出,Web 格式的选择应当具有针对性、高效性以及狭窄的作用域。WebP 虽然在最初的定位上略显局限,但其背后的理念 - - 为 Web 量身定制 - - 始终值得借鉴。AVIF 虽然在容器规范以及 AV1 对某些图像属性的规范化处理上仍有提升空间,但凭借其庞大的生态与 AV1 视频编码的深度耦合,已经成为了 Web 图像压缩的事实上的标准。
JPEG XL 作为一个旨在兼顾一切的格式,在 Web 语境下显得过于宽泛,这也正是它难以在浏览器中站稳脚跟的原因之一。值得注意的是,作者并非完全否定 JPEG XL 的价值。他对 JPEG XL 在 Web 外的潜在发展充满希望:专业工作流中的 Adobe 套件、相机厂商、智能手机 OEM 以及其他非 Web 领域的专业用户,或许才是 JPEG XL 真正的受益者。在摄影后期、RAW 图像传输、高保真存储等场景下,JPEG XL 的无损压缩优势、广色域支持以及渐进式解码能力或许能够找到更适配的环境。正如他在之前的访谈中所言,希望能看到一个既有 AVIF 又有 JPEG XL 的 Web 生态,让开发者根据各自需求权衡选择,而非强制某种格式的普及。归结而言,JPEG XL 的案例为我们提供了一个关于技术与平台博弈的深刻启示。
图像压缩格式的成功不能仅依赖于编码算法的理论优越性,更必须考量浏览器的原生支持情况、解码性能对硬件的影响、开发者的实际作业流以及安全性等多重因素。在 Web 日益对速度、稳定性和生态协同提出更高要求的今天,JPEG XL 那种试图"一格走天下"的设计理念,在面对 AVIF 与 WebP 那样聚焦 Web 需求的格式时,显得尤为突兀。当然,这并不意味着 JPEG XL 将彻底失去价值,正如作者所乐观展望的那样,它完全有机会在 Web 之外的专业领域中占据一席之地,与 AVIF 在不同的应用场景中并存、互补。对于 Web 端的图像压缩而言,未来或许不再是单一格式的霸权,而是多种格式根据内容类型、设备能力以及传输环境的自适应选择。开发者在面对日益丰富的图像格式时,理解每种格式的权衡点、适用边界以及背后的技术权衡将比单纯追求某一格式的优劣更为重要。JPEG XL 的兴衰之路虽已画下了一个阶段的句号,但它所引发的思考 - - 关于格式选择的理性、关于平台责任的考量以及关于技术生态演进的辩证法 - - 将继续指引着图像压缩领域的后续发展。
在技术不断进化、需求多元化的今天,唯有兼顾理论与实践、创新与兼容,才能在 Web 的浪潮中找到最适合的图像编码解决方案。 。