Hacker News 熱門

Firefox 157 will include JPEG XL by default on all platforms

· 49天前
跳到正文

正文

Groups
Groups





Intent to ship: JPEG XL

3,270 views
Skip to first unread message

Timothy Nikkel's profile photo

Timothy Nikkel

unread,
Aug 24, 2026, 7:15:09 PM (2 days ago) Aug 24



Reply to author
Sign in to reply to author
Forward
Sign in to forward
Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
to dev-pl...@mozilla.org

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


Timothy Nikkel's profile photo

Timothy Nikkel

unread,
Aug 24, 2026, 7:37:11 PM (2 days ago) Aug 24



Reply to author
Sign in to reply to author
Forward
Sign in to forward
Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
to dev-pl...@mozilla.org
一丝's profile photo

一丝

unread,
Aug 25, 2026, 4:22:05 PM (10 hours ago) Aug 25



Reply to author
Sign in to reply to author
Forward
Sign in to forward
Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
to dev-pl...@mozilla.org, tni...@mozilla.com
Is Animated JXL currently supported?

Timothy Nikkel's profile photo

Timothy Nikkel

unread,
Aug 25, 2026, 4:40:26 PM (10 hours ago) Aug 25



Reply to author
Sign in to reply to author
Forward
Sign in to forward
Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
to 一丝, dev-pl...@mozilla.org
Yes. Animated jxl is supported.

Tim

Sergey Davidoff's profile photo

Sergey Davidoff

unread,
Aug 25, 2026, 6:40:40 PM (8 hours ago) Aug 25



Reply to author
Sign in to reply to author
Forward
Sign in to forward
Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
to dev-pl...@mozilla.org, tni...@mozilla.com
I am concerned about lossless JPEG XL performance. In my measurements it is 30x slower to decode than lossless WebP, in exchange for a 10% reduction in file size. This is a questionable trade-off, especially on laptops and phones where it could drain battery and degrade user experience.

I suggest shipping only lossy JPEG XL in Firefox 157, and considering lossy JPEG XL format separately.

Measurement methodology

I've used https://github.com/sharkdp/hyperfine which measures execution time over multiple runs and collects statistics

jxl-rs from git https://github.com/libjxl/jxl-rs on commit 775837f57dfe4294d89c1c6317dd91a1ed8d3cfa compiled with 'cargo build --release'

converted to WebP with 'cwebp -lossless', to JPEG XL with 'cjxl -d 0'

Both decoders running in single-threaded mode to measure total CPU time taken with 'taskset -c 0'.

$ hyperfine --warmup 5 'taskset -c 0 target/release/jxl_cli --speedtest 55_Cancri_e_Final_1_30.jxl' 'taskset -c 0 dwebp 55_Cancri_e_Final_1_30.png.webp'
    Benchmark 1: taskset -c 0 target/release/jxl_cli --speedtest 55_Cancri_e_Final_1_30.jxl
      Time (mean ± σ):     20.632 s ±  0.061 s    [User: 20.605 s, System: 0.027 s]
      Range (min … max):   20.549 s … 20.743 s    10 runs
     
    Benchmark 2: taskset -c 0 dwebp 55_Cancri_e_Final_1_30.png.webp
      Time (mean ± σ):     667.0 ms ±   2.2 ms    [User: 449.5 ms, System: 217.5 ms]
      Range (min … max):   664.3 ms … 670.1 ms    10 runs
     
    Summary
      taskset -c 0 dwebp 55_Cancri_e_Final_1_30.png.webp ran
       30.93 ± 0.14 times faster than taskset -c 0 target/release/jxl_cli --speedtest 55_Cancri_e_Final_1_30.jxl

For reference, libjxl's djxl tool is 20x slower than WebP in the same measurement. So it doesn't look like further optimizations to the Rust code could help, but would not change the overall calculus.

понедельник, 24 августа 2026 г. в 12:15:09 UTC+1, tni...@mozilla.com:

Reply all
Reply to author
Forward

0 new messages

查看原文(Hacker News 熱門)