Firefox 157でJPEG XLが全プラットフォームでデフォルトで有効化

出荷意向: JPEG XL Firefox 157の時点で、全プラットフォームでJPEG XLデコーディングをデフォルトで有効にする予定です。これはこれまで `image.jxl.enabled` の設定で有効化されており、今日ではNightlyのみでデフォルトでオンになっており、バージョン152以降すべてのチャネルでFirefox Labsのチェックボックスがありました。デコーダーはRust製の `jxl-rs` です。 バグ（デフォルトでの有効化）: https://bugzilla.mozilla.org/show_bug.cgi?id=2065096 標準: ISO/IEC 18181, https://www.iso.org/standard/85066.html 標準化団体: ISO/IEC プラットフォーム対応: 全て 設定項目: image.jxl.enabled 標準の位置づけ: https://github.com/mozilla/standards-positions/issues/522 (中立) TAGレビュー: https://github.com/w3ctag/design-reviews/issues/633 (懸念事項に満足) プロトタイプ意向: https://groups.google.com/a/mozilla.org/d/msgid/dev-platform/53b4e3e0-5eee-4768-a1ba-b069e1e85244n%40mozilla.org 他のブラウザ: Safariは2023年の17.0で出荷済みです。Chromeは `#enable-jxl-image-format` の設定で同じRustライブラリを使用していますが、出荷意向はまだありません。 プロトタイプ意向以降の変更点: パフォーマンスはプロトタイプ意向スレッドで提起された懸念事項でした。`jxl-rs` 0.6.0がマルチスレッドデコーディングサポート付きでリリースされ、マルチスレッドデコーディングをフックして有効化するためのパッチがまもなくマージされる見込みです。これらのパッチを含め、さまざまなサイズの同じ画像に対する5つのフォーマットのデコードベンチマークを実行しました。私のマシンでは、Safari（C++ `libjxl` を使用）をわずかに上回りました。他の画像フォーマットデコーダーと比較して、JXLは大きな画像では同等ですが、小さな画像では差が大きくなります。 アニメーションとプログレッシブ表示を含め、他の画像フォーマットやBlinkのJXL実装との機能パリティがあります。唯一の例外はHDRです。HDR画像はSDRとして表示され、サポートしている他のフォーマットと同じですが、JXLのトーンマッピングは他の画像フォーマットよりも優れています。Safariにはプログレッシブレンダリングもアニメーションもありません。 `wpt` の `jpegxl` ディレクトリは、ビット深度、アルファ、グレースケール、CMYK、カラーマネジメント、向き、コーディングツール全体でのデコードの正確性をカバーしており、さらにHTMLとCSSでの画像の利用方法も含まれています。`wpt` で表現できなかったものについては、Geckoテストを追加しました。チャンク処理およびインクリメンタルデコーディング、アニメーションフレーム数、デコード中のダウンサイジング、破損ファイルに関する約30のgtest、プログレッシブレンダリングとテレメトリに関するmochitest、reftest、およびPerfherderに報告されるデコードベンチマークです。ファジングチームは、Nightlyで有効化される前にすでに `jxl` をファジングしており、プリファレンスを切り替える前にデコーダーを再度ファジングする予定です。 Chromiumからの出荷意向: https://groups.google.com/a/chromium.org/g/blink-dev/c/-gDojQbDPRI アニメートされたJXLは現在サポートされていますか？ はい。アニメートされたJXLはサポートされています。 ロスレスJPEG XLのパフォーマンスについて懸念しています。私の測定では、ロスレスWebPと比較してデコード速度が30倍遅く、ファイルサイズは10%削減されるだけです。これは特にラップトップやスマートフォンでバッテリーを消耗させ、ユーザーエクスペリエンスを低下させる可能性があるため、疑問のあるトレードオフです。Firefox 157ではロスレスJPEG XLのみを出荷し、ロスレスJPEG XLフォーマットは別途検討することを提案します。 測定方法: `https://github.com/sharkdp/hyperfine` を使用して、複数回の実行で実行時間を測定し、統計情報を収集しました。 `jxl-rs` はgit（https://github.com/libjxl/jxl-rs）のコミット `775837f57dfe4294d89c1c6317dd91a1ed8d3cfa` から、`cargo build --release` でコンパイルしました。 入力画像: https://commons.wikimedia.org/wiki/File:55_Cancri_e_Final_1_30.png WebPには `cwebp -lossless` で、JPEG XLには `cjxl -d 0` で変換しました。 両方のデコーダーをシングルスレッドモードで実行し、`taskset -c 0` を使用して合計CPU時間を測定しました。 $ 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 参考として、`libjxl` の `djxl` ツールは同じ測定でWebPより20倍遅いです。したがって、Rustコードのさらなる最適化は全体的な計算を変えることはないでしょう。