Vergelijking met andere browsers

• Safari: Geïmplementeerd in versie 17.0 (2023).
• Chrome: Beschikbaar via de vlag #enable-jxl-image-format (gebruikt dezelfde Rust-bibliotheek), maar er is nog geen intentie om dit standaard uit te rollen.

Wijzigingen sinds het prototype

Prestaties en decodering

Tijdens de prototypefase waren er zorgen over de prestaties. Inmiddels is jxl-rs 0.6.0 uitgebracht met ondersteuning voor multithreaded decodering. De patches om deze multithreaded decodering in Firefox te activeren, worden binnenkort geïmplementeerd.

Uit benchmarks waarbij vijf verschillende formaten werden getest op diverse afbeeldingsgroottes, bleek dat Firefox op de testmachine iets sneller was dan Safari (dat gebruikmaakt van de C++ libjxl). Vergeleken met andere interne image-decoders presteert JXL bij grote afbeeldingen vergelijkbaar, maar is er een groter verschil merkbaar bij kleine afbeeldingen.

Functionaliteiten

JPEG XL heeft nu functionele pariteit met andere ondersteunde image-formaten en de JXL-implementatie van Blink, inclusief ondersteuning voor animaties en progressieve weergave.

Uitzondering: HDR HDR-afbeeldingen worden momenteel weergegeven als SDR, wat consistent is met alle andere ondersteunde formaten. Echter, de tone mapping voor JXL is aanzienlijk beter dan die voor andere formaten. Ter vergelijking: Safari ondersteunt momenteel geen progressieve rendering of animaties.

Testen en kwaliteitsborging

De correctheid van de decodering is uitgebreid getest via de wpt jpegxl directory. Dit omvat:

• Bitdiepten, alpha-kanalen, grijstinten, CMYK en kleurbeheer.
• Oriëntatie en coderingstools.
• Gebruik van afbeeldingen binnen HTML en CSS.

Daarnaast zijn er specifieke Gecko-tests toegevoegd voor zaken die WPT niet kon dekken:

• Ongeveer 30 gtests voor chunked en incrementele decodering, animatie-framecounts, downscaling tijdens decodering en corrupte bestanden.
• Mochitests voor progressieve rendering en telemetrie.
• Reftests en decode-benchmarks die rapporteren aan Perfherder.

Het fuzzing-team heeft jxl reeds getest voordat het in Nightly werd ingeschakeld en zal de decoder opnieuw fuzzen voordat de voorkeursinstelling definitief wordt omgezet.

Discussie over prestaties van verliesvrije (lossless) JPEG XL

Er is een zorg geuit over de prestaties van de verliesvrije modus van JPEG XL. Uit metingen blijkt dat de decodering van verliesvrije JXL ongeveer 30 keer trager is dan die van verliesvrij WebP, terwijl de bestandsgrootte slechts met 10% afneemt. Dit kan leiden tot een hogere batterijconsumptie en een slechtere gebruikerservaring op laptops en telefoons. Er is daarom gesuggereerd om in Firefox 157 alleen de lossy (met kwaliteitsverlies) variant van JPEG XL te implementeren en de verliesvrije variant apart te overwegen.

Meetmethodologie van de benchmark

Voor deze meting is gebruikgemaakt van hyperfine om de executietijd over meerdere runs te bepalen.

• Tooling: jxl-rs uit git (commit 775837f57dfe4294d89c1c6317dd91a1ed8d3cfa), gecompileerd met cargo build --release.
• Testbeeld: 55CancrieFinal130.png
• Omgezet naar WebP via cwebp -lossless.
• Omgezet naar JPEG XL via cjxl -d 0.
• Configuratie: Beide decoders draaiden in single-threaded modus (taskset -c 0) om de totale CPU-tijd te meten.

$ 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