Firefox 157 将在所有平台上默认启用 JPEG XL。
Firefox 157 will include JPEG XL by default on all platforms

原始链接: https://groups.google.com/a/mozilla.org/g/dev-platform/c/3YMV4MS34KA?pli=1

Mozilla 计划从 Firefox 157 版本开始,在所有平台上默认启用 JPEG XL 解码。该解码器使用了基于 Rust 的 `jxl-rs` 库,并已完成广泛的测试、模糊测试和基准测试。 主要亮点包括: * **性能:** `jxl-rs` 最近的更新增加了多线程解码功能,使 Firefox 的解码性能可与 Safari 的 C++ 实现相媲美。 * **功能:** 该实现支持动画、渐进式显示,以及针对 HDR 内容的高质量色调映射。 * **兼容性:** 通过支持动画和渐进式渲染,Firefox 的功能集已超过 Safari。 * **质量保证:** 该项目包含了全面的 Web 平台测试 (WPT) 以及涵盖分块解码、损坏处理和遥测技术的自定义 Gecko 测试。 在此之前,用户可通过 `image.jxl.enabled` 首选项使用此功能,该选项目前在 Nightly 版本中已默认开启。开发进度,包括性能基准测试和完整的测试套件,可通过所引用的 Mozilla Bugzilla 报告进行追踪。

Firefox 157 将原生支持 JPEG XL 图像格式,这得益于名为 `jxl-rs` 的全新内存安全 Rust 实现。该解码器由 Google Research 应 Mozilla 要求开发,是浏览器采用此格式的关键前提。据报道,Chromium 也将采用同一实现。 JPEG XL 因其相较于 WebP 和 AVIF 等现有格式的多项技术优势而受到关注。主要益处包括: * **旧版兼容性:** 它允许对现有 JPEG 文件进行 100% 可逆的无损转换,在无需重新编码的情况下节省 20–30% 的文件大小。 * **卓越的通用性:** 它在有损和无损压缩方面均优于 WebP 和 AVIF,支持高位深(最高 16 位/浮点数),并能处理超大尺寸和多样的色彩通道。 * **渐进式加载:** 其架构专为高效的渐进式解码而设计,仅需极少部分数据即可显示高质量缩略图。 尽管 AVIF 此前一直是传统 JPEG 的主要替代方案,但用户和开发者普遍认为 JPEG XL 是一种更灵活、更具前瞻性的标准图像格式替代品。
相关文章

原文

As of Firefox 157 I intend to turn JPEG XL decoding on by default on all platforms. It has been developed behind image.jxl.enabled, which today is on by default on Nightly only, and has had a Firefox Labs checkbox on every channel since 152. The decoder is jxl-rs, in Rust.

Bug to turn on by default: https://bugzilla.mozilla.org/show_bug.cgi?id=2065096

Standard: ISO/IEC 18181, https://www.iso.org/standard/85066.html

Standards body: ISO/IEC

Platform coverage: all

Preference: image.jxl.enabled

Standards position: https://github.com/mozilla/standards-positions/issues/522 (neutral)

TAG review: https://github.com/w3ctag/design-reviews/issues/633 (satisfied with concerns)

Intent to prototype: https://groups.google.com/a/mozilla.org/d/msgid/dev-platform/53b4e3e0-5eee-4768-a1ba-b069e1e85244n%40mozilla.org

Other browsers: Safari shipped in 17.0 in 2023. Chrome has it behind #enable-jxl-image-format using the same Rust library, no intent to ship yet.

Changes since the intent to prototype:

Performance was a concern raised on the intent to prototype thread. jxl-rs 0.6.0 was released with multithreaded decoding support, and our patches to hook up and enable multithreaded decoding are expected to land soon. Including those patches, I ran a five-format decode benchmark over the same pictures at a range of sizes: we were slightly ahead of Safari (using C++ libjxl) on my machine. Compared to our other image format decoders, JXL is close on large images, but shows a bigger gap on small ones.

It has feature parity with our other image formats and with Blink's JXL implementation, including animation and progressive display. The one exception is HDR: HDR images display as SDR, the same as every other format we support, but our tone mapping for JXL is much better than what we do for other image formats. Safari has neither progressive rendering nor animation.

The wpt jpegxl directory covers decode correctness across bit depths, alpha, grayscale, CMYK, colour management, orientation and the coding tools, plus the HTML and CSS ways an image gets used. Where wpt could not express something I added gecko tests: about 30 gtests for chunked and incremental decoding, animation frame counts, downscale during decode and corrupt files, mochitests for progressive rendering and telemetry, reftests, and decode benchmarks that report to Perfherder. The fuzzing team already fuzzed jxl before it was enabled on nightly and they will fuzz the decoder again before I flip the pref.

Timothy Nikkel


联系我们 contact @ memedata.com