JPEG XL に対する考察

JPEG XLのウェブ画像コーデックとしての位置づけを調査する。なぜか？ JPEG XLは技術的に印象的な画像コーデックである。JPEGよりも明確に優れており、WebPよりも汎用性が高く、ウェブ以外のユースケースにも対応できる能力を備えている。しかし、2023年にChromeでの採用が見送られたことは有名である。ロイヤリティフリーで柔軟性があり、圧縮効率の高いJPEG委員会によるコーデックが大手企業から注目されていたにもかかわらず、この決定は多くの人々に受け入れられなかった。最近、Rust製のJPEG XLデコーダーが、ある程度FirefoxとChromeに搭載された。これにより、ウェブの主要な関係者はJPEG XLに対する方針を転換する可能性がある。なぜなら、新しいデコーダーは、ウェブが2023年のWebPの脆弱性を再経験するのを防ぐかもしれないからだ。これだけでJPEG XLをウェブに正当化するのに十分だろうか？ 歴史的に、私はあらゆるユースケースでJPEG XLの大きな支持者であった。私はInterop 2024でJPEG XLを支持し、フォーマットの主要な著者であるJon Sneyers氏やJyrki Alakuijala氏とも個人的に何度も交流してきた。彼らの公の場での振る舞い、冷静さ、技術的適性、そしてこの分野への情熱には常に感銘を受けている。この記事は、フォーマットの著者やその業績を貶めることを目的としたものではなく、フリーソフトウェアにおけるコーデックの象徴性に関連する政治的所属を主張するものでもない。この記事の精神は教育的である。2026年における画像圧縮とウェブプラットフォームの現状を経験的に考察したい。Dmitry Grinberg氏のRISC-V: They Should Have Known Betterからインスピレーションを得ている。 ウェブにおける画像圧縮 私は元々ビデオ圧縮から画像圧縮の分野に入った。AV1エンコーダーに取り組んでいる際に、Julio Barba氏と私はAVIFに大きな進歩をもたらし、その過程で多くのことを学んだ。自分でエンコーダーを構築しようと決めたとき、どのフォーマットが最も高い天井を持ち、効果的に最適化でき、最も現在および将来的な有用性があるかを真剣に考える必要があった。私はJPEG XLでの作業を選択しなかった。量的に見ると、ウェブ上では汎用的な損失圧縮で対応できないユースケースは非常に少ない。平均的なウェブ利用者はロスレスを必要としない。彼らはひどいアーティファクト（例えば、非写真コンテンツにおけるJPEG）を防ぐのに十分な汎用性を持つ損失圧縮コーデックを必要としているだけだ。これはJPEG XLのロスレスの利点を排除する。実際には、ロスレスWebPよりも約11.9%小さいだけだが、それはウェブにとって非現実的なテストデータセット（157MPの写真、10MPのイラスト、27MPの本）に基づいている。帯域幅の制約に本来敏感でないユースケースで、ごくわずかな画像コンテンツの12%を節約するために、ブラウザに新しい画像コーデックを導入する価値はない。私がこのように言うのは、JPEG XLは損失圧縮では競争力がないため、ロスレスが唯一の本当の利点となるからだ。 損失圧縮効率 JPEG XLの当初の主張の一つは、そのリファレンスエンコーダーが競合エンコーダーよりも知覚的に最適化されているということだった。現在では、速度とビットあたりの忠実度の両方で、他のエンコーダーの方が強力である。AV1リファレンスエンコーダーは、知覚的な指標を維持するチューニングモードを備えつつ、効率を高めるために制御された主観的な人間の試験に基づいて専門的な知覚チューニングを受けている。SVT-AV1も同様のチューニングモードを持っている。現代のエンコーダーが人間の目にチューニングされていないという説得力のある議論はない。指標は完璧ではないが、JPEG XLにとっては厳しい状況を示している。 CVVDPMS-SSIMSSIMULACRA2 Aperture-alphaはHalide Compressionの今後のエンコーダーで、コードネームはApertureである。最先端で競争するためにlibjxlがどれだけ差を埋める必要があるかを示すために含めた。一部の分析では、JPEG XLは知覚的な強さに比べて指標で劣ると主張しているが、共有したグラフのようなものが完全に逆転するほどの程度であるという十分な証拠は見ていない。CVVDPとSSIMULACRA2は非常に強力な知覚指標であり、差がこれほど大きい場合は確かに何かを示している。AVIFの場合、libaomの知覚的に最適化されたチューニング（tune IQ）は、知覚指標に最適化されたチューニング（tune SSIMULACRA2）よりもわずか数ポイント低いだけである。さらに、JPEG XLのリファレンスエンコーダーは、歴史的に知覚的な問題に悩まされており、それは大部分未解決のままである。コーデックのベンチマークというものは存在せず、エンコーダーのベンチマークしか存在しない。理論的には、JPEG XLのフォーマットとしての天井はlibjxlが達成しているよりも高い。しかし、そのギャップを埋めるのはどれほど難しいだろうか？ 圧縮エンジニアとして、私はそれが不利であると信じている。その理由をいくつか挙げる。 JPEG XLには方向性予測モードがない。圧縮された画像はVarDCTブロック（2x2から256x256まで）に分割され、ピクセルの周波数表現に変換される。WebPのような他のブロックベースの画像コーデックでは、周囲のデータを使用してブロックのピクセルを予測し、その予測を実際のピクセルから減算してから周波数変換を行うことができる。方向性予測モードは、エンコーダーが知覚的に最適化されていない場合、ぼやけを引き起こす可能性があるが、強力なモード決定パイプラインは、その仕事に適したモードを選択し、多くのビットを節約できる。例えば、エッジの保存性は方向性予測を持つコーデックの方が優れているが、JXLはこの点で劣る。エッジ保存性のギャップに対する提案されている解決策はスプラインだが、これは使用するのがはるかに難しい。難しいのはエンコーダー側である。スプラインで表現できるピクセルがどれだけあるかを判断する効率的なアルゴリズムが必要であり、その後、候補をすべてRDO（Rate-Distortion Optimization）に通して、コーディングする価値があるかどうかを決定する必要がある。スプラインをエッジ保存に使用した既存のPoC（Proof of Concept）はなく、方向性予測よりも優れていると信じる理由はない。 JPEG XLにはデブロッキングループフィルタリング（DLF）や、いかなるデブロッキングフィルタも搭載されていない。2つのインループツールが部分的な同等物として提供されることがある。gaborishは、JXLがAV1のループ復元フィルタリングに最も近いものであり、EPF（エッジ保存フィルタ）は、AV1のCDEFに最も近いものである。どちらもデブロッキングフィルタではなく、この2つを組み合わせても適切なDLFを完全に置き換えることはできない。DLFは画像を滑らかにすることができるが、エンコーダーが賢ければ、JPEG XLが依然として苦しんでいるモスキートノイズを回避するのに役立つだけである。 JPEG XLの知覚色空間「XYB」は多くの直感に基づいており、SSIMULACRA2のような指標が全く同じ色空間で機能する場合でも、他のフォーマット（JPEGなど）での利点に必ずしも変換されない。XYBの使用による主張される効率的な節約も、libjxlが現在積極的にBチャンネルを量子化に依存しているため、当初広告されたほど大きくはない。これにより、色の保存性が低下し、新しいJXLエンコーダー開発者はこれを明示的に元に戻す必要がある。 JXLは非写真画像に弱い。提案されている解決策はパッチだが、AV1のIntra Block Copyよりも使用が難しい。IntraBCと同等の表現範囲を得るには、エンコーダーはレイヤーやブレンディングといった追加の概念を扱う必要があるが、ビットストリームレベルでの表現にはコストがかかる。残差コーディングは扱いにくい。AV1では、ブロックを予測し、ソースから予測を減算し、変換係数が自然に残差を表す。JXLの構造では、残差フレームをデコードしてから参照パッチをブレンドするため、実際のフレームまたはデコードされたピクセルが残差を表すレイヤーが必要になる。これはおそらくモジュラーフレームになるだろう。モジュラーフレームは、最終的にレンダリングされる画像とは異なり、従来の符号なし画像値に限定されないため興味深い。IntraBCブロックは基本的にモーションベクトルと残差係数をコストとするが、JXLの構造は参照フレーム、フレームヘッダー、クロップ、ブレンド情報、パッチ辞書エントリ、パッチ座標、残差フレームをコストとする可能性がある。このオーバーヘッドは、繰り返し領域がかなり大きいか、何度も再利用されない限り、節約分を圧倒する可能性がある。パッチは、現在のパフォーマンスの問題のため、努力レベル7未満でlibjxlで明示的に有効にする必要がある。非写真画像に対する「それらはベクター画像であるべきだ」という議論は、多くの画像が…