コーデック比較をじっくり考える

 (cloudinary.com)
10 ポイント 投稿者 lifthrasiir 2022-12-15 | 2件のコメント | WhatsAppで共有

Chrome が JPEG XL の実験を中止するというニュース（https://ja.news.hada.io/topic/… AVIF 側が自分たちで比較したベンチマーク資料を公開して反論したことがあります（https://storage.googleapis.com/avif-comparison/… JPEG XL 側の反論です。

単に JPEG XL 擁護／反対という話を離れて、画像フォーマットの比較において重要な点を押さえているので読む価値があります。要点をいくつか整理すると:

  • AVIF 側のデコード速度は Chrome および libjxl の古いバージョンに基づいており、そのため誇張されている。最近のバージョン基準では JPEG XL（基本設定）~= 12ビット AVIF < JPEG XL（高速デコード設定）~= 8ビット AVIF < JPEG から再圧縮した JPEG XL であり、各不等号の差は 10% 程度しかない。

  • 全体のデコード速度よりも、利用可能な画像がどの時点で表示されるかのほうが重要であり、JPEG XL はプログレッシブ（progressive）デコードをサポートするため、ここで大きな利点を持つ。（Web で Largest Contentful Paint のような話をするのと同じ文脈です）

  • エンコード性能とエンコード済み画像の品質を別々に比較しているが、libjxl はエンコード性能とエンコード品質を完全に独立して調整できる一方、AVIF をはじめとする他のエンコーダの大半ではこれが不可能なため、そのように比較することはできない。

  • 提示されたエンコード時の目標品質範囲が広すぎ、確率分布が考慮されていない。"On the fly" と呼ばれた最低品質は、誰もどの用途でも使えないほど低品質である。また AVIF は平均的に低画質画像で強い傾向があるが、少しでもファイルサイズが大きくなると JPEG XL が大きく上回ることが多く、これを不適切な方法で平均化したため、JPEG XL の強みが薄められる結果になった。

  • テストに使われたデータセットが不適切である。可逆圧縮では雑誌画像をスキャンした Kodak セットを使い、非可逆圧縮には通常ベクターグラフィックや可逆圧縮を使う Noto Emoji セットが含まれているが、どちらも一般的に可逆・非可逆圧縮を使うユースケースではない。

  • 画像圧縮性能が現在のための議論だとすれば、画像フォーマットがサポートする機能は未来のためのものである。いったんブラウザに入った画像フォーマットを削除できないのであれば、それだけなおさら機能に重点を置いて評価すべきだ。

関連記事

2件のコメント

 
lifthrasiir 2022-12-15

出勤前に急いで書いたため細かく間違っている部分があるのですが（…）、on the fly は厳密に言えば最低品質ではなく最高速度です（ただし JPEG XL を除くほとんどのエンコーダでは、品質と逆相関の関係にあります）。また、Kodak データセットは自分でもなぜそう書いたのか分かりませんが雑誌だと書いてしまいました。ただ、実際にはフィルムからスキャンされたものです。