JPEG XL批判、圧縮ではAVIFが上回ると主張

Gianni Rosato氏が2026年9月13日、JPEG XLに対する詳細な技術的批判を公開しました。現在のAVIFエンコーダーは、画質域の全体でJPEG XLを上回るという主張です。この時期はウェブで画像を配信する人すべてに関係します。Firefox 157がJPEG XLを既定で有効にする予定が、9月末だからです。

JPEG XLは2022年にISO/IEC 18181として標準化された画像フォーマットです。AVIFは動画コーデックのAV1を土台にした競合フォーマットです。どちらも、見た目の品質が同じならJPEGより小さいファイルを目指しています。

数字の前に知っておくべきことが1つあります。Rosato氏は競合フォーマットの側で働いています。本人は画像圧縮の仕事をしていると書き、「AV1エンコーダーの作業中に、Julio Barba氏と私はAVIFを大きく前進させた」と述べています。この点は記事の中で本人が明かしています。それで測定値が誤りになるわけではありません。ただし、第三者がまだ検証していないということです。

記事の主張

Rosato氏はまずフォーマットの長所を認めます。「JPEG XLは技術的に見事な画像コーデックであり、JPEGからの明確な進歩だ」と書いています。批判の対象はAVIFと比べたJPEG XLであり、JPEGと比べたJPEG XLではありません。

可逆圧縮では、現実的なウェブ向けの素材で、JPEG XLは可逆WebPより約11.9%小さいと測っています。フォーマットが要求する手間に対して、見返りは小さいという評価です。非可逆圧縮では、現在のAVIFエンコーダーが3つの知覚指標で上回ると報告しています。CVVDP、MS-SSIM、SSIMULACRA2の3つです。これらの指標は、変化した画素を数えるのではなく、2枚の画像が人にどれだけ似て見えるかを推定します。「AVIFは今や画質域の全体を支配している」と同氏は書いています。

JPEG XLに無い圧縮ツールも挙げています。方向性予測モードが無く、デブロッキングループフィルターも無いという指摘です。方向性予測は、エンコーダーが画素ブロックを角度に沿って隣から予測する仕組みで、硬い輪郭で効きます。デブロッキングフィルターは、圧縮ブロックのあいだに見える継ぎ目をなめらかにします。この2つが無いことが、スクリーンショットや線画のような写真以外の画像でフォーマットの上限になっていると同氏は論じます。

デコード爆弾

もっとも鋭い主張は、ファイルサイズではなくデコード時間についてです。Rosato氏はprime wallと呼ぶ、意図的に作った画像を紹介しています。サイズは1,918バイトで、M5 Proでのデコードにユーザー時間で17.43秒かかりました。同氏はこう書いています。「prime wallの画像はわずか1,918バイトだ。だから低性能な端末をJXLで爆撃するのは、もうすぐ簡単になる」

これは品質への苦情ではなく、サービス妨害（DoS）の形です。2キロバイトのアップロードがCPUを数秒消費するなら、利用者が送った画像をデコードするサービスすべてにとって問題になります。同氏はこの穴を、JPEG XL仕様の表現力の高さに帰しています。仕様上は正しく、同時に極端に遅い構成があるということです。

デコードについては、さらに2つの報告があります。同氏のテストではWebPのデコードがJPEG XLより10倍以上速いというものです。もう1つは、プログレッシブ表示がAVIFでも動くようになった点で、これはJPEG XLに残っていた最も明確な利点の1つでした。

両者が測っている基準は別

速度の話は、JPEG XLプロジェクト自身の成果によって単純ではなくなります。jxl-rsは、プロジェクトがChromeとFirefoxの両方で使われていると説明するRust製のデコーダーです。リポジトリは目標として、仕様への完全な準拠を挙げています。公式のC++参照実装であるlibjxlより、メモリ安全性とデコード性能を高めることも掲げています。プロジェクトは、jxl-rsがその参照実装にほぼ並び、時には上回り、メモリ使用量は少ないとしています。

これらの主張とRosato氏の主張は、正面からぶつかってはいません。同氏はJPEG XLをWebPとAVIFに対して測っています。プロジェクトは新しいRustデコーダーを、自分たちの古いC++デコーダーに対して測っています。デコーダーが前の版に勝ちながら、WebPには負けることはありえます。2つを合わせて読むと、デコード速度は実際に進歩しており、Rosato氏が報告する差はまだ埋まっていません。

開発者にとっての意味

記事1本でフォーマットを変えないでください。上のどの数字も1人の著者のテストセットから出ており、その著者は比較で勝つ側のフォーマットで働いています。正しい対応は自分の画像で測ることです。圧縮の結果は内容によって大きく振れます。

今月やる価値があることが3つあります。1つめは、本番の画像から実際のサンプルを取り、AVIFとJPEG XLの両方で符号化し、実際に配信する品質でサイズを記録することです。2つめは、ノートPCではなく安価なスマートフォンでデコード時間を測ることです。3つめは、画像のアップロードを受け付けているなら、デコードに時間とメモリの上限を厳しくかけ、意図的に扱いにくいファイルで試すことです。

3つめはJPEG XLを配信するかどうかに関係なく価値があります。prime wallはJPEG XLの例ですが、現代のコーデックにはどれも病的な入力があります。デコードの予算を持たないアップロード経路こそが本当の不具合です。

ほとんどのサイトでは、Mozillaの出荷告知以降、実務的な助言はあまり動いていません。普通の写真にはAVIFを使い、非常に大きい画像のプログレッシブ表示が重要な場面ではJPEG XLを使ってください。この批判が加えるのは、2つめの前提を測り直す理由です。AVIFのプログレッシブ対応は、もはやかつての弱点ではありません。