JPEG XLとパレートフロント
(cloudinary.com)- 大きな画像を一括処理していたJPEG XLエンコードのボトルネックを、libjxl 0.10がストリーミングエンコードAPIで軽減し、ロスレス圧縮のメモリ使用量と速度を大幅に改善
- 13500×6750のNASA夜間地球画像のロスレスエンコードは、libjxl 0.9の約8GB RAM・2分以上から、libjxl 0.10では0.7GB RAM、シングルスレッド30秒、8スレッド5秒に短縮
- 圧縮方式の比較はファイルサイズだけでは不十分で、エンコード速度と圧縮密度をあわせて見るパレートフロントが、時間予算ごとの最適設定を見極める基準になる
- ロッシー圧縮では圧縮率・速度・画質を同時に見る必要があり、SSIMULACRA2 60〜90の範囲でJPEG XLは特に高画質〜視覚的ロスレス領域で強い結果を示す
- jpegliのような新しいJPEGエンコーダも、非常に高速なエンコード領域では依然として競争力があるが、JPEG XLは幅広い速度範囲でロスレス・ロッシー圧縮の双方における主要な選択肢として定着
libjxl 0.10の主な変更点
- libjxl 0.10はJPEG XL参照実装の新バージョンであり、最大の変更点はストリーミングエンコードAPIの完全実装
- このAPIは大きな画像を一括で処理せず、チャンク単位でエンコードする
- 画像全体をメモリに載せる際に生じるRAM負荷が減る
- エンコード速度もあわせて改善される
- 特に大きな画像のロスレス圧縮で効果が目立つ
ロスレス圧縮で削減されたメモリと時間
- libjxl 0.10以前のロスレスJPEG XLエンコードでは、大きなメモリと長い処理時間が問題になり得た
- 例に使われた画像はNASAの13500×6750夜間地球画像
- TIFFファイルは64MB
- 圧縮前サイズは273MB
- デフォルトのeffort設定e7で同じ画像を圧縮した結果:
- libjxl 0.9は約8GB RAMを使用し、2分以上かかり、出力ファイルは33.7MBだった
- シングルスレッドは2分40秒、8スレッドは2分6秒で、スレッド増加の効果は大きくなかった
- 測定環境は12コアApple M3 Pro CPUと36GB RAMを搭載した2023年11月のMacBook Pro
- libjxl 0.10では、同じ画像の圧縮に0.7GB RAMしか必要ない
- シングルスレッド30秒
- 8スレッド5秒
- 出力ファイルは33.2MB
- effort値を上げると圧縮率は向上するが、CPU時間に対する改善幅は次第に小さくなる
- e1からe2に上げ、0.1秒の代わりに1秒を使うと22MB削減できた
- e2からe7に上げ、1秒の代わりに5秒を使うと、さらに11MB削減できた
- e7からe9に上げ、さらに1MB削減するには、ほぼ2分待つ必要があった
effort設定の実用的な妥協点
- 圧縮設定は時間とファイルサイズの間のトレードオフ
- 画像編集中にローカルへ保存する制作ワークフローでは、強い圧縮が必ずしも必要ではないため、低いeffortでのエンコードが合理的な場合がある
- 一対多の配信シナリオや長期保存では、CPU時間を多く使って数MB削減する選択に価値がある場合がある
パレートフロントで圧縮方式を比較する
- 圧縮技術を比較する際、ファイルサイズだけを見ると、実際の選択に必要な情報を見落としやすい
-
比較軸とチャートの読み方
- 重要な軸は圧縮密度とエンコード速度
- ある方式がパレート最適であるとは、同じまたはより高い圧縮密度をより短い時間で達成する別の方式がないという意味
- パレート最適な方式の集合がパレートフロント
- チャートでは縦軸がエンコード速度、横軸が圧縮後画像の平均bits per pixel
- 縦軸はmegapixels per second単位で、幅広い速度範囲を扱うために対数スケールを使用
- 圧縮前の8ビットRGBは24bpp
- 上に行くほど速く、左に行くほど圧縮率が良い
ロスレス圧縮の比較結果
- 以前のlibjxlも、すべての速度範囲でパレート最適の結果を出しており、PNG・ロスレスAVIF・ロスレスWebPより小さいファイルを生成していた
- libjxl 0.10は以前のバージョンよりかなり大きな差で良い結果を示す
- QOIはチャートには表示されていないが、154Mpx/sで17bppを記録
- libjxlの最も低いeffort設定は427Mpx/sで11.5bppまで圧縮
- libjxlの方が2.7倍速く、出力ファイルは32.5%小さかった
非写真画像におけるロスレス圧縮
- 写真は自然ノイズが多く、ロスレス圧縮が難しい傾向があり、非写真画像では結果が変わる
- 多様な絵柄の漫画画像41枚を使ったテストで、平均サイズは7.3メガピクセルだった
- こうした画像は約4bppまで圧縮され、写真画像の約10bppよりはるかによく圧縮される
- ロスレスAVIFはこの画像タイプでは有用ではなかった
- PNGより圧縮率が低かった
- QOIと似た密度には達したが、はるかに遅かった
- ロスレスWebPはこの種の画像で非常に良い圧縮率を示す
- QOIは速度と単純さを考慮すれば悪くないが、パレート最適からは遠い
- 低effortのJPEG XLエンコードはQOIより2倍速く、31%小さかった
- libjxl 0.10は非写真画像でも0.9から大きく改善
- WebPデフォルトeffortは4.30bpp、2.3Mpx/s
- libjxl 0.9 effort 5は4.27bpp、2.6Mpx/s
- libjxl 0.10 effort 5は4.25bpp、12.2Mpx/s
- libjxl 0.10 effort 7は4.04bpp、5.9Mpx/s
ロッシー圧縮では画質の軸が加わる
- ロスレス圧縮は圧縮サイズと速度だけを見ればよいが、ロッシー圧縮では画質が加わる
- ロッシー画像コーデックとエンコーダは、品質ポイントによって性能が変わる場合がある
- 高画質エンコードで優れたエンコーダが、低画質でも優れているとは限らない
- 逆も同様
- 圧縮率と画質だけを見るbitrate-distortionプロットでは、エンコードeffortと圧縮性能の間のトレードオフを評価しにくい
- ロッシー圧縮のパレートフロントを見るには、圧縮・速度・画質の3次元空間を複数の品質ポイントで切り出して見る必要がある
画質測定と集計方法
- 画像の画質は主観的で、人によって異なり得る
- 最も良い測定方法は、数十人以上の人が厳密なテストプロトコルに従って画像を比較または採点する実験
- こうした実験は時間と費用がかかり、すべてのエンコーダ設定をテストするのが難しいため、客観指標が使われる
- 公開指標の中で良いものとして、SSIMULACRA2、Butteraugli、DSSIMが挙げられる
- これらは人間の視覚システムをモデル化しようとしており、主観評価との相関が高い
- PSNRやSSIMのような古い単純指標は、人間の画質判断とうまく合わない
- エンコーダが内部的に最適化している指標で評価すると、結果がそのエンコーダに有利に歪む可能性がある
- 高effortのlibjxlはButteraugliを最適化する
- libavifはPSNRまたはSSIMを最適化できる
- SSIMULACRA2は、テストされたエンコーダが内部最適化に使っていないため、安全な指標として扱われる
- テストでは、各設定を画像セット全体に適用したときの平均SSIMULACRA2スコアが特定の値に近くなるようにエンコーダ設定を選んだ
- 平均スコアで揃える方法はWebPとAVIFに有利な方式
- 以前の研究では、AVIFとWebPはJPEG・HEICより一貫性が低く、JPEG XLは最も一貫性のあるエンコーダだった
- 実運用では、最悪スコアまたは実際の最悪の視覚品質を揃えたい場合がある
実使用に近い品質範囲
- ロッシー圧縮では50:1や200:1のような高い圧縮率も可能だが、圧縮アーティファクトが発生する
- 実使用で関連性が高い範囲はSSIMULACRA2 60〜90
- 品質ポイントごとの特性:
- SSIMULACRA2 90: 視覚的ロスレス品質で、AVIFやJPEG XLのような現代的コーデックは約8:1の圧縮率、つまり3bppで到達できる
- SSIMULACRA2 80: 高画質で、約16:1の圧縮率、つまり1.5bppで到達できる
- SSIMULACRA2 70: 中上品質で、約30:1の圧縮率、つまり0.8bppで到達できる
- SSIMULACRA2 60: 中程度の品質で、約40:1の圧縮率、つまり0.6bppで到達できる
- SSIMULACRA2 60より低い品質は帯域幅をさらに減らせるが、画像を損なうリスクがある
- 2024年のWebでは、中〜高画質の範囲が関連性が高い
- HTTP Archive基準でWeb上のAVIF中央値は1bppで、中上品質に相当
- JPEG中央値は2.1bppで、高画質に相当
- カメラのような非Webユースケースでは、高画質〜視覚的ロスレスの範囲の方が関連性が高い
ロッシー圧縮のパレートフロント結果
- ロッシー圧縮テストは、2024年2月末時点の各エンコーダの最新バージョンで実施
- エンコード速度は、Apple M3 Proベースの2023年11月MacBook Proで8スレッドにより測定
- AVIFはタイル設定と非タイル設定の両方をテスト
- タイル設定はマルチスレッド活用が良く、より高速
- その代わり圧縮密度の損失がある
中程度の品質: SSIMULACRA2 60
- 同じフォーマット内でも、エンコーダとeffort設定によって結果に大きな差があった
- 歴史的に広く使われてきたJPEGエンコーダであるlibjpeg-turboのデフォルト設定は、チャートで最速だが圧縮密度は低い側に位置する
- WebPはlibjpeg-turboより圧縮密度が良かった
- mozjpegはlibjpeg-turboより遅いが、より良い圧縮結果を提供し、この画像セットと品質ポイントではWebPよりパレート効率が高かった
- GoogleのJPEG XLチームが作ったjpegliは、mozjpegより速く圧縮率も良かった
- guetzliとlibjxlから得た教訓に基づいている
- WebPや高速AVIFよりよく圧縮しながら、従来のJPEGファイルを生成する
- AVIFとHEICはJPEG・WebPより高い圧縮密度を得られるが、エンコードはより遅かった
- JPEG XLは近い圧縮密度に到達しつつ、はるかに高速にエンコードする
- この品質ポイントのパレートフロントは、妥当な速度帯ではJPEG XLと複数のJPEGエンコーダ、より遅い領域ではAVIFで構成される
中上・高画質の結果
- SSIMULACRA2 70の中上品質では、全体の結果は中程度の品質と似ていた
- Webに関連する最も高い品質ポイントとして平均SSIMULACRA2 85を使用し、ほとんどの画像が80以上を達成するよう設定
- この高画質ポイントでは差がより明確になる
- mozjpegはもはやWebPに勝てなかった
- jpegliは依然としてWebPに勝った
- パレートフロントの大部分はJPEG XLが占めた
- 非常に高速なエンコードでは従来のJPEGが依然として優れていた
- この品質ポイントでAVIFはパレートフロントに入らなかった
- 最も遅い設定で0.5Mpx/s以下の速度となり、2番目に速いlibjxl設定と同じ圧縮密度に合わせた
- そのlibjxl設定は52Mpx/sで、100倍以上速かった
デコード速度
- ここまでの比較は圧縮密度とエンコード速度が中心だった
- 現代のコンピュータではデコード速度は大きな問題ではないが、測定値も比較されている
- シーケンシャルJPEGはデコード速度で最も強い
- mozjpegとデフォルトのjpegliが生成するプログレッシブJPEGはより遅いが、妥当なサイズの画像を非常に速く読み込むには十分高速
- JPEG XLはシーケンシャルJPEGとプログレッシブJPEGの間に位置する
- AVIFのデコード速度はエンコード方式によって変わる
- より高速だがわずかに悪いマルチタイルエンコードを使うと、デコードも速くなる
- デフォルトのシングルタイルエンコードはより遅い
- 測定された最も遅いデコード速度も、エンコード速度と比べれば十分に速い部類
視覚的ロスレスと大きな画像
- 視覚的ロスレス品質のチャートにはWebPが含まれていなかった
- ロッシーモードではこの品質ポイントに到達できなかった
- WebPでは4:2:0クロマサブサンプリングが必須のため
- mozjpegもこの品質ポイント向けに設計されておらず、libjpeg-turboより圧縮と速度の両方で悪かった
- デフォルト速度設定でlibavifはlibjpeg-turboより20%小さかったが、エンコードには一桁長い時間がかかった
- 同じ品質ポイントでlibjxlはlibavifより20%小さく、2.5倍速かった
- 視覚的ロスレス品質のパレートフロントは大部分をJPEG XLが占め、最速の速度帯にはJPEGも含まれる
- Webサイズ画像の約1メガピクセルテストとは異なり、より大きな画像のテストでは結果が大きく変わる
- 高画質ポイントでWebP、mozjpeg、AVIFはlibjpeg-turboより悪かった
- HEICはlibjpeg-turbo比でかなりの削減を提供
- jpegliもより良い速度でかなりの削減を提供
- JPEG XLは画像を1.3bpp未満に圧縮し、AVIF・libjpeg-turbo・WebPは2bpp以上が必要だった
libjxl 0.10の最終的な位置づけ
- libjxl 0.10はロスレス・ロッシー圧縮の双方でメモリ使用量を一桁規模で削減
- 速度も改善され、特にマルチスレッドのロスレスエンコードにおけるデフォルトeffort設定は一桁規模で高速化
- JPEG XLはロスレスとロッシー圧縮の双方で、特に高画質〜視覚的ロスレス品質範囲に強い画像コーデックとして整理できる
- 幅広い速度設定範囲で、JPEG XLはパレート最適に近い選択肢であり続けている
- 従来のJPEGも新しいエンコーダのおかげで依然として魅力的
- jpegliはmozjpegより速度と圧縮の両方で大きく改善
- 極めて高速なエンコードが必要な場合、従来のJPEGが依然として最善の選択となり得る
2件のコメント
jpegliエンコーダがmozjpegに続いて、またしてもjpgを延命させていますね...
JXL陣営が作ったものですが、皮肉にもJXLの普及を妨げることになるかもしれませんね...
Hacker News の意見
ロスレス WebPがどれほど優れているかにも注目すべき
WebP は MozJPEG エンコードに比べて明確な利点がない、あるいは劣るという話に埋もれがちだが、ロスレス WebP は性能と速度の面で本当に優れている
PNG や OptiPNG よりはるかに良く、オンラインでのサポートも十分になっており、出来の悪いロスレス AVIF を大きく上回るのは当然
SDR 画像には問題ないが、HDR では GIF が256色に制限されるのと同じくらい根本的な制約になる
漫画全体を圧縮するなら PNG が依然として適切で、この場合は実質的に廃れた optipng より oxipng を使うほうがよい
さらにここで抜けている点として、ロスレス JPEG2000 は写真コンテンツでは意外に良く、速いことがある
実際のロスレスより多くの用途で好ましく、さらに目に見える劣化なしにサイズを半分にできることが多い
非常に低い品質設定では、JPEG は目立つアーティファクトのせいで近くで見るとキュビスム絵画のように崩れていても、画像全体の品質をよりよく保つシャープなディテールの近似を維持しているのが驚き
実質的に画像をある種の抽象芸術スタイルに変えているようなものだが、JXL と AVIF は単にぼやける
これらの画像は同じ圧縮率ではなく同じ歪みレベルに合わせようとしたもので、ピクセル当たりのビット数は画像の横に表示されている
実際のインターネットで品質65を使うことはまれで、最低品質のサイトで使われる程度であり、品質75がよくある低品質、品質85が平均に近い
圧縮が必要なときは品質94 yuv444 以上を使う
ビットレートは左列にあり、低品質 JPG は JXL/AVIF の中低品質である 0.4bpp と同じサイズなので、左下の画像を上中央と右の画像と比較すべき
誤った比較に引きずられてはいけないし、JXL と AVIF もファイルサイズを2倍与えればずっと良く見える
SSIMULACRA2 はブロックアーティファクトを強く罰する一方で、ぼかしにはあまり気を使わないようで、同じ SSIMULACRA2 スコアなら JPEG 版のほうが良く見えるという点には同意する
この記事がなぜエンコード速度にはそこまで集中する一方で、Web 接続環境で使用量の99%に当たると思われるデコードを軽く扱っているのか理解できない
「デコード速度は現代のコンピューターでは大きな問題ではないが、数値をざっと見るのは興味深い」程度で流している
その時点からボトルネックはもはやデコードではないから
現代の圧縮アルゴリズムの多くは非対称で、圧縮にははるかに多くの時間を使っても展開性能には大きく影響しないため、基本性能を達成すれば重要度は下がる
可能なら、現在のハードウェアではすべてソフトウェアでデコードしなければならない JPEG XL より、これらを好む強い理由になり得る
H264 デコードはどこにでもあり、AV1 デコードも着実に標準機能になりつつある
クライアントがページ上の数枚の画像を人間が感じ取れないほど速くデコードできれば十分で、逆にエンコードで数％でも改善されれば実際のコスト削減につながる
実際に画像エンコードに数百万ドルを使っている
ロスレスのベンチマークに QOI が入っているのを見て笑ってしまった
一般向けソフトウェアで標準サポートされておらず、優れているというより「そこそこ」を目指す、実質的には無関係なフォーマットなのに、非写真エンコードのチャートで一枠を占めている点が興味深い
そのため GameMaker Studio とここ2年ほどに作られたゲームは、実際に内部で QOI を使っている
消費者が意識して使うものではないが、完全に無関係とも言い難い
振り返れば当然で、QOI のデコードは本質的に逐次的なので簡単には並列化できない
JXL の素晴らしさがフォーマット自体のおかげなのか、エンコーダのおかげなのか気になる
-d 1.0だけで高品質かつ小さい画像を作れる能力は不思議なほどで、ほかのコーデックでは似た結果を得るには画像の種類に応じて品質設定を変える必要があったこの開発速度なら libjxl が画像エンコーダ界の x264 になっても驚かない
逆に libvpx は常に平凡なエンコーダで、それが vp8/vp9 フォーマットの残念な性能、速度だけでなく全般的な性能の原因かもしれないと思う
これは必然的に非可逆 WebP の性能にも影響し、Dark Shikari が x264 と vp8 の静止画像性能も比較したことがある [0]
[0] https://web.archive.org/web/20150419071902/http://x264dev.mu...
視覚的ロスレスに多くの焦点を置き続けており、高い品質設定に役立たず複雑さだけを増やすフォーマット機能は入れたくなかった
モデリング機能に加えて、コンテキストモデリングとエントロピー符号化の効率は高品質では非常に重要
AVIF のエントロピー符号化は、高品質またはロスレス写真にはあまり向いていないと思う
-d 1.0インターフェースを持つ JPEG エンコーダ cjpegli も作ったJPEG XL の取り組みから Highway という優れた新しい並列化ライブラリも生まれた点は触れておく価値がある
このライブラリは JPEG XL だけでなく、Google の最新 Gemma AI モデルにも使われている
[1] でも扱っていて、冒頭はこうだ。「今日、私たちは数値配列を C++
std::sortより約 10 倍速くソートし、すべての現代的な CPU アーキテクチャで移植性を維持しながら、最新のアーキテクチャ別アルゴリズムよりも高速なオープンソースコードを共有します。以下では、これをどのように達成したかを説明します。」[0] https://github.com/google/highway
[1] https://opensource.googleblog.com/2022/06/Vectorized%20and%2...、関連論文は https://arxiv.org/pdf/2205.05982.pdf
C++ でポータブルな SIMD を得る最良の方法のように見える
JPEG XL がそれ自体でどれほど輝いているかとは別に、次のことができるだけでも間違いなくすごい
a.jpgは 615504 バイトで、SHA-1 は716744d950ecf9e5757c565041143775a810e10fcjxl a.jpg a.jxlを実行すると、615504 バイトの JPEG を読み込み、コンテナ込みで 537339 バイトに圧縮するところが
djxl a.jxl b.jpgを実行すると、537339 バイトの圧縮データを読み込んで JPEG に再構成し、b.jpgも 615504 バイトで SHA-1 が完全に同じになる保存したい JPEG ファイルが世界に何十億もあることを考えると、既存の JPEG を非可逆フォーマットで再圧縮すれば品質は下がる
しかし JPEG XL は 15〜30% を節約しながら、望めば元の JPG をビット単位で 100% 同一に戻せる
本当に素晴らしい
残念ながら Debian stable 12 Bookworm を使っていて ImageMagick は 6.9 で、Emacs が画像を表示するときはおそらく ImageMagick を使っていると理解している
JPEG XL 対応は ImageMagick 7 になってようやく追加され、まだそれ以上は掘り下げていない
非可逆な再エンコードなしでデジタル遺産を完全に保存する助けになると思う
libjxl の新バージョンが非可逆・ロスレス圧縮の両方で メモリ使用量を一桁規模で減らし、速度も改善した点がとても印象的
特にマルチスレッドのロスレスエンコードにおけるデフォルトの effort 設定が今では一桁規模で速くなったという部分が良く、記事もよく書かれていた
JPEG XL フォーマットの各段階を詳しく説明するウェブサイトがあるのか気になる
従来の JPEG と違い、関連する段階を明確に案内する文書を見つけにくく、このフォーマットには興味深い革新が多く集まっているのは明らかなので残念
個々の構成要素も、それ自体で有用そうだ
核心は最大 128x128 までの 可変サイズ DCT、ANS エントロピー予測、輝度ベースの色差予測
https://github.com/libjxl/libjxl/blob/main/doc/encode_effort... も effort レベルごとの機能の違いをよく示している
記事には AV1、したがって AVIF をエンコードする rav1e が抜けている
rav1e は参照実装である aom よりはるかに速く、aom が 1 分待っても画像変換を終えられなかった一方で、rav1e は 10 秒もかからなかった場合があった
高速な rav1e が高いエンコード速度では jpegli より良く見えるのかも気になる
同程度の速度では、両者の間で圧縮性能に大きな差が出るのを見たことはない