JPEG XL に対する考察

JPEG XL に対する見解

Web画像コーデックとしてのJPEG XLの立ち位置を調査する。

［画像: Caustics］

なぜか？

JPEG XLは技術的に印象的な画像コーデックであり、JPEGの決定的なアップグレードであり、WebPよりも汎用性が高く、Web以外のユースケースにも対応できる十分な機能を備えています。しかし、2023年にChromeから却下されたことは有名です。JPEG委員会によるロイヤリティフリーで柔軟、かつ圧縮効率の高いコーデックが大手企業から注目を集めていたにもかかわらず、この決定は多くの人に受け入れられませんでした。

最近、Rust製のJPEG XLデコーダーがFirefoxやChromeの一部で採用されました。主要なWebステークホルダーは、この新しいデコーダーが2023年のWebP脆弱性の再発からWebを保護する可能性があるため、JPEG XLの方針を転換しているのかもしれません。これだけでWebにおけるJPEG XLを正当化するには十分なのでしょうか？

歴史的に、私はあらゆるユースケースでJPEG XLの大きな支持者でした。Interop 2024でJPEG XLを支持し、フォーマットの主要な著者であるJon Sneyers氏やJyrki Alakuijala氏とは個人的に何度も交流しました。彼らの公の場での振る舞い、冷静さ、技術的適性、そしてこの分野への情熱には常に感銘を受けています。

この記事は、フォーマットの著者やその業績を貶めることを目的としたものではなく、また、フリーソフトウェアにおけるコーデックのシンボリズムに関連する政治的所属を主張するものでもありません。この記事の精神は教育的なものです。2026年における画像圧縮とWebプラットフォームの現状を経験的に見ていきたいと思います。Dmitry Grinberg氏の「RISC-V: They Should Have Known Better」からインスピレーションを得ています。

Web

私は画像圧縮の仕事をしており、元々はビデオ圧縮の分野から来ています。AV1エンコーダーの開発中に、Julio Barba氏と私はAVIFに大きな進歩をもたらし、その過程で多くのことを学びました（詳細はこちら）。自身のエンコーダーを構築することにしたとき、どのフォーマットが最も高いポテンシャルを持ち、効果的に最適化でき、現在および将来の有用性が最も高いかを真剣に考える必要がありました。私はJPEG XLでの作業を選択しませんでした。

量的に見ると、Web上では汎用的な損失圧縮で対応できないユースケースは非常に少ないです。平均的なWebユーザーはロスレスを必要としません。彼らが必要とするのは、ひどいアーティファクト（例: 非写真コンテンツにおけるJPEG）を防ぐのに十分な汎用性を持つ損失コーデックです。これはJPEG XLのロスレス優位性を除外します。実際、ロスレスWebPと比較して約11.9%小さいに過ぎず、しかもWebには非現実的なテストデータセット（1億5700万枚の写真、1000万枚のイラスト、2700万冊の本）に基づいています。帯域幅の制約に敏感でないユースケースの、ごくわずかな画像コンテンツに対して12%を節約するために、ブラウザに新しい画像コーデックを導入する価値はありません。JPEG XLは損失圧縮では競争力がないため、ロスレスが唯一の本当の利点となるからです。

損失圧縮効率

JPEG XLの当初の主張の一つは、そのリファレンスエンコーダーが競合エンコーダーよりも知覚的に最適化されているというものでした。現在では、速度とビットあたりの忠実度の両方において、他のエンコーダーの方が優れています。

AV1リファレンスエンコーダーは、知覚効率を強化するために、管理された主観的な人間の試行に基づいた知覚チューニングを受けており、知覚メトリクスに最適化されたチューニングモードを維持しています。SVT-AV1も同様のチューニングモードを持っています。現代のエンコーダーが人間の目に合わせてチューニングされていないという説得力のある議論はありません。

メトリクスは完璧ではありませんが、JPEG XLにとっては厳しい状況を示しています。

［画像: CVVDP］［画像: MS-SSIM］［画像: SSIMULACRA2］

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つのインループツールが部分的な同等物として提供されることがあります。一つは、JXLがAV1のループ復元フィルタリングに最も近いものであるgaborish、もう一つはEPF（エッジ保存フィルタ）で、AV1のCDEFに最も似ています。どちらもデブロッキングフィルタではなく、両方を組み合わせても適切なDLFを完全に置き換えることはできません。DLFは画像を滑らかにすることができますが、エンコーダーが賢ければ、JPEG XLが依然として苦しんでいるモスキートノイズを回避するのに役立つだけです。
• JPEG XLの知覚色空間「XYB」は多くの直感に基づいており、SSIMULACRA2のようなメトリクスが全く同じ色空間で機能する場合でさえ、他のフォーマット（JPEGなど）での利点に常に変換されるわけではありません。XYBを使用することによる主張される効率的な節約も、libjxlが現在Bチャンネルの積極的な量子化に依存しているため、当初広告されたほど大きくありません。これにより、色の保存が不十分になり、新しいJXLエンコーダー開発者はこれを明示的に元に戻す必要があります。
• JXLは非写真画像でパフォーマンスが低いです。提案されている解決策はパッチの使用ですが、AV1のイントラブロックコピー（Intra Block Copy）よりも使用が困難です。
  • IntraBCと同様の表現範囲を得るには、エンコーダーはレイヤーやブレンディングなどの追加概念を扱う必要がありますが、ビットストリームレベルでの表現にはコストがかかります。
  • 残差コーディングが厄介です。AV1では、ブロックを予測し、予測をソースから減算し、変換係数が自然に残差を表します。JXLの構造では、残差フレームをデコードしてから参照パッチをブレンドするため、残差を表す実際のフレームまたはレイヤーが必要になります。これはおそらくModularフレームになるでしょう。Modularは、最終的なレンダリング画像とは異なり、従来の符号なし画像値に限定されないため興味深いです。
  • IntraBCブロックは基本的にモーションベクトルと残差係数を必要としますが、JXLの構造は参照フレーム、フレームヘッダー、クロップ、ブレンド情報、パッチ辞書エントリ、パッチ座標、および残差フレームを必要とする可能性があります。このオーバーヘッドは、繰り返し領域がかなり大きいか、何度も再利用されない限り、節約分を圧倒する可能性があります。
  • パッチは、パフォーマンスの問題があるため、現在、libjxlではレベル7未満で明示的に有効にする必要があります。

非写真画像に対して、「それらはベクター画像であるべきだ」という議論は成り立ちません。なぜなら、多くの画像はベクター画像になり得るのにそうではなく、完全にベクター化できないからです。「世界は違うべきだ」というのは、世界が実際にどうなっているかに合わせて最適化することに対する正当な弁護にはなりません。

これらの点が、天井がlibjxlが到達できる範囲よりも高く、より良いものができることを意味すると考えるのは魅力的ですが、その直感的でない（そして潜在的に弱い）コーディングツールを考えると、最適化されたAVIFエンコーダーにすぐに追い越すことができるとは確信できません。

デコード時間

JPEG XLは驚くほど柔軟な仕様を持っています。コーディングツールに加えて、最大4096チャンネル、任意のビット深度、プログレッシブデコード、JPEG再圧縮などをサポートしています。これらの機能の多くはWebでは広く利用されていません。4チャンネル（RGB/YUV + アルファ）、HDRをサポートするための合理的なビット深度（10ビットで十分）、そして高速にロードできる能力が必要です。

プログレッシブレンダリング（AVIFはサポートしている）は、完全な画像が到着する前に低忠実度のレンディションをデコードします。AVIFはしばらくの間プログレッシブレンダリングをサポートしておらず、その間、私はそれが過大評価されていたと信じています。libavifがそれを実装した今（常に可能でした）、議論は終わったようです。これは、結果がそれ自体を物語っているからだと思います。

［画像: AVIF Progressive Decode］

これはJPEG-XL info siteからのもので、AVIFは完全な画像のわずか約2〜3%のサイズで、JXLよりもはるかに早く使用可能な画像を表示しています。AVIFが全体的にも小さいことを考えると、これは容易な勝利です。AVIFプログレッシブデコードはChromeでのみ機能するため、ページをスクリーンショットしました。これはブラウザのネイティブデコーダーを使用しています。JPEG XLはポリフィルを使用しています。Safariでサポートされている場合でも、プログレッシブデコードは利用できません。

JPEG再圧縮は、JPEGをJXL画像としてロスレスで再エンコードし、ビットを節約する機能です。しばしば引用される数値は20%の節約です。しかし、ユーザーはデコード時間でその代償を払います。再圧縮されたJPEGのデコードには約33%長くなります。現代のコンシューマーデバイスは強力ですが、「節約は無料で得られる」という議論は誤解を招きます。

その件について、デコード時間は最速のものと競争できません。

［画像: Decode Time］

公開の議論では、AVIFはデコードが遅いと考えられています。ではJXLはどうでしょうか？これは10ビットAVIFであり、すべての画像は同じソースのサイズマッチングエンコードでした。JPEGは2,478,828バイト、JPEG XLは2,599,428、AVIFは2,649,949、WebPは2,693,794でした。WebPは90KB以上大きく、それでもwpdでjxl-rsよりも10倍以上速くデコードできます。

コーデックの表現力のため、途方もなく長いデコード時間を要する画像を細工することが可能です。この例（注意して開いてください）は、33,599までの素数を計算し、私のM5 ProでRustデコーダーを使用して17.43秒のユーザー時間を要します。さらに、これはChrome、Firefoxなどに搭載されつつあるデコーダーであることを覚えておいてください。素数壁の画像はわずか1,918バイトなので、SafariでネイティブにJPEG XLをサポートしているため、低スペックデバイスをJXL爆弾で簡単に遅くできるようになります。すでにWebページに数十個のこれらの画像を含めて、Appleデバイスを遅くすることができます。

結論と意見

Webコーデックは、目的に特化され、効率的で、Webのニーズに狭くスコープされているべきだと私は信じています。WebPは少しスコープが狭すぎたと思いますが、そのアイデアはありました。AVIFのコンテナはもっと良くできるかもしれませんし、AV1仕様は画像の特定のプロパティ（例: 規範的な4:2:0アップサンプリング）の処理についてもう少し具体的にできるかもしれませんが、AVIFは常にAV1のおかげでWebへの確実な追加であり、非常に成熟したエコシステムから恩恵を受けています。

では、JPEG XLは必要でしょうか？それは全く狭くスコープされていません。設計上、すべての人にすべてを提供するものです。他の多くのユースケースではこれが求められていると思いますが、Webは帯域幅を節約し、高速にデコードし、フットガン（誤操作）を防ぐ必要があります。JPEG XLがWebPよりも優れているとは思いません。ましてや、インターネットから画像をダウンロードしてどこかで使おうとする人にとって、追加の互換性の問題が生じることです。WebPの普及でさえ十分困難でしたし、AVIFとJPEG XLの両方で同じ丘を登るために痛みを倍増させる価値はないと思います。特にJPEG XLがWebプラットフォームに何も追加していないように見える場合。

3年半前、私はこう言いました。

AVIFとJPEG XLの両方が存在し、開発者がそのメリットに基づいてフォーマットを選択できるWebを望んでいます。[...] 私の意見では、JPEG XLとAVIFは根本的に異なる強みを持っており、それぞれ異なるユースケースに適しています。

当時、JPEG XLは中〜高忠実度の損失画像圧縮において、はるかに強力な候補でした。現在、AVIFは忠実度範囲全体を支配しているため、JPEG XLの唯一の本当の利点は消滅しました。

［画像: Full Fidelity Range］

JPEG XLはCloudinaryとGoogleから生まれましたが、コーデックがそのように議論されていないと思います。JPEG XLとAVIFの両方がロイヤリティフリーであることも言及する価値があります。Googleのブラウザ市場支配を巡る政治、GoogleからのAV1、そしてGoogleのWebPを巡る論争のため、JPEG XLの議論の多くは、技術的に優れた画像コーデックを望むというよりも、より多くの開発者選択肢を持つWebを望むことから来ているというのが私の意見です。私はこれを理解しており、JPEG XLはAVIFが決して到達できなかった場所で、Web以外の場所で依然として成功できると信じています。同じ記事で：

私の現在の楽観的な希望は、JXLがAdobeスイートなどのプロフェッショナルツールや、カメラメーカー、スマートフォンOEMなどの間で普及し、それらがJXLをより真剣に検討し始めることです。

JPEG XLは無用ではありません。Web以外のユースケースにとっては、確かに魅力的な技術です。私は個人的には、近い将来ブラウザで必要になるとは確信していません。

ソフトウェアと環境の詳細。