There are at least three reasons to ship lossless and lossy JXL at the same time: 1) Lossless JXL is already shipped in Safari. Even if it were possible to draw a line between lossy and lossless, doing so would cause ecosystem fragmentation, which is undesirable. Moreover, the current speed does not seem to have caused significant problems in Safari. 2) The speed obtainable by lossless JXL is significantly better than what the email above suggests - first of all, jxl_cli's --speedtest option will run two decodes by default. Moreover, the encoder can be configured to prioritize decoding speed over maximum compression -- for example, setting --faster_decoding 1 does not change the compressed size significantly, but doubles decoding speed. Also, note that the linked image is almost 100 megapixels and strongly benefits from multi-threaded decoding. 3) Not all possible use-cases of JPEG XL lossless are covered by webp, i.e. >8bpc content.
On Tue, Aug 25, 2026 at 3:47 PM Sergey Davidoff <[email protected]> wrote: > I am concerned about lossless JPEG XL decoding 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 am *especially* concerned about CDNs adopting lossless JPEG XL to save > <10% on bandwidth costs, and externalizing those costs by degrading my > phone's battery life. > > I suggest shipping only lossy JPEG XL initially, where the benefit is > clearly demonstrated, and considering lossless 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' > > Input image: > https://commons.wikimedia.org/wiki/File:55_Cancri_e_Final_1_30.png > 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:08:20 UTC+1, Chromestatus: > >> *Contact emails* >> [email protected], [email protected] >> >> *Explainer* >> *No information provided* >> >> *Specification* >> https://www.iso.org/standard/85066.html >> >> *Summary* >> Adds support for decoding JPEG XL (image/jxl) images in Blink using >> jxl-rs, a memory-safe pure Rust decoder (https://github.com/libjxl/jxl-rs). >> JPEG XL is a modern image format standardized as ISO/IEC 18181 that offers >> progressive decoding for improved perceived loading performance, support >> for wide color gamut, HDR, and high bit depth, and support for animation. >> >> *Blink component* >> Internals>Images>Codecs>JPEG XL >> <https://issues.chromium.org/issues?q=customfield1222907:%22Internals%3EImages%3ECodecs%3EJPEG%20XL%22> >> >> *Web Feature ID* >> jpegxl <https://webstatus.dev/features/jpegxl> >> >> *Motivation* >> (see Summary) >> >> *Initial public proposal* >> *No information provided* >> >> *TAG review* >> https://github.com/w3ctag/design-reviews/issues/633 >> >> *TAG review status* >> Issues addressed >> >> *Goals for experimentation* >> >> >> *Risks* >> >> >> *Interoperability and Compatibility* >> No special risks. Note that the C++ and the Rust version are both tested >> against the same conformance test corpus. >> >> *Gecko*: Shipped/Shipping also migrating to rust version >> >> *WebKit*: Shipped/Shipping WebKit currently uses the C++ decoder. >> >> *Web developers*: Strongly positive >> >> *Other signals*: >> >> *WebView application risks* >> >> Does this intent deprecate or change behavior of existing APIs, such that >> it has potentially high risk for Android WebView-based applications? >> New feature, no special risk >> >> >> *Debuggability* >> *No information provided* >> >> *Will this feature be supported on all six Blink platforms (Windows, Mac, >> Linux, ChromeOS, Android, and Android WebView)?* >> Yes >> >> *Is this feature fully tested by web-platform-tests >> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?* >> Yes >> https://wpt.fyi/results/jpegxl?label=experimental&label=master&aligned >> There is extensive conformance testing outside of WPT too. WPTs show >> failures because the flag is disabled in wpt runs. >> https://wpt.fyi/results/jpegxl?sha=3d06a34791fc33532baffe64e5c48c450cb1a1b9 >> shows a run with the flag enabled, which has two failures. The >> icc-uncommon-profile-reftest.html failure is a small difference visually, >> currently investigating. The cmyk-basic-conversion-reftest.html failure is >> being fixed in >> https://chromium-review.git.corp.google.com/c/chromium/src/+/8275513 >> >> *Flag name on about://flags* >> enable-jxl-image-format >> >> *Finch feature name* >> JXLImageFormat >> >> *Rollout plan* >> Will ship enabled for all users >> >> *Requires code in //chrome?* >> False >> >> *Availability expectation* >> Feature is available on Web Platform Baseline within 12 months of launch >> in Chrome. >> >> *Adoption expectation* >> Feature is considered a best practice for some use case within 12 months >> of reaching Web Platform baseline. >> >> *Adoption plan* >> Multiple players on the web have expressed interest in deploying JPEG XL >> images, including at least Cloudinary and Shopify, as well as multiple web >> developers during the Interop process. >> >> *Non-OSS dependencies* >> >> Does the feature depend on any code or APIs outside the Chromium open >> source repository and its open-source dependencies to function? >> No. >> >> *Estimated milestones* >> >> No milestones specified >> >> >> *Anticipated spec changes* >> >> Open questions about a feature may be a source of future web compat or >> interop issues. Please list open issues (e.g. links to known github issues >> in the project for the feature specification) whose resolution may >> introduce web compat/interop risk (e.g., changing to naming or structure of >> the API in a non-backward-compatible way). >> N/A >> >> *Link to entry on the Chrome Platform Status* >> https://chromestatus.com/feature/5114042131808256?gate=6594362739916800 >> >> This intent message was generated by Chrome Platform Status >> <https://chromestatus.com>. >> > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJUR5SCgFoDaQdgq61PdnLCTzXpH3bVb7if0kfH%2B-o219jgiRA%40mail.gmail.com.
