HN 日本語サマリー

← 一覧へ戻る
Web開発

ウェブ利用におけるJPEG XL vs AVIF

JPEG XL vs. AVIF for web use-cases (jakearchibald.com)

75 pointsby farlight53 コメント

要約

この記事は、ウェブサイトでの画像フォーマットとしてJPEG XLとAVIFを比較検討しています。ロスあり写真ではAVIFが一般的にファイルサイズで優位ですが、ロスなし画像ではJPEG XLが優れています。スクリーンショットやイラスト、透明度が必要な画像ではAVIFが、デコード速度でもAVIFが有利であることが示されています。最終的には、多くの場合AVIFをデフォルトとし、必要に応じてJPEG XLを試すことが推奨されています。

全文翻訳

ウェブ利用におけるJPEG XL vs AVIF 投稿日: 2026年10月15日 JPEG XLが主要ブラウザすべてに導入されたので、他のフォーマットと比較して何が得意で何が不得意なのかを詳しく見てみることにしました。 結論 詳細な例とベンチマークを交えて説明しますが、時間のない方のために要点をまとめます。 ロスあり写真の場合、ウェブ上ではAVIFがJPEG XLよりもほぼ常にファイルサイズが小さくなります。デフォルトの試行設定では、最高のJPEG XLバージョンは同等のAVIFよりも通常15~25%大きくなります。最大試行設定では、その差はわずかに縮まり、通常6~20%になります。JPEG XLがAVIFに近い、あるいは上回る例外も存在するため、特定の画像で絶対的な最良の結果を得たい場合は、両方を試す価値があります。典型的な例としてF1の画像、例外としてイタチの画像を参考にしてください。 JPEG XLエンコーダーは非常に重要です。新しいJPEG XLエンコーダーであるjixelは、画像に詳細な透明度がある場合を除き、通常libjxlよりも小さなファイルを生成します。peopleの画像はその一例です。 スクリーンショットやイラストの場合、AVIFはJPEG XLよりもはるかに優れています。デフォルトの試行設定では同等のJPEG XLは30~90%大きく、最大試行設定では20~70%大きくなります。ロスありAVIFはこれらをうまく処理します。ビット単位で正確な結果が本当に必要な場合を除き、ロスレスフォーマットを使用する必要はありません。スクリーンショットとイラストの例を参照してください。 透明度のある画像の場合、AVIFはJPEG XLよりもはるかに優れています。libjxlバージョンは、デフォルトの試行設定で31~44%大きく、最大試行設定で61~70%大きくなります。jixelは常に透明度をロスレスでエンコードするため、ファイルサイズはAVIFの2~3倍になります。データの例を参照してください。 エンコード速度とメモリ使用量 ファイルサイズを考慮すると、AVIFは一般的にエンコードが速く、メモリ使用量も少なくなります。jixelはAVIFよりも高速でメモリ使用量も少ないですが、ファイルサイズは通常大幅に大きくなるため、全体としてはAVIFの方が優れています。F1の画像はその一例です。 デコード速度 AVIFはデコードが速いです。JPEG XLは通常、中程度の品質でデコードに2~3倍の時間がかかりますが、非常に高い品質ではその差は縮まり、Chromeは時々JPEG XLの方が速くデコードできることがあります。peopleの画像はその一例です。 高試行設定の価値 AVIFとjixelでは高試行設定の価値がありますが、libjxlではそうではありません。libjxlの高試行設定は非常に遅く、メモリを大量に使用し、結果はほとんど改善されません。時にはデフォルト設定よりも大きなファイルを生成することもあります。スクリーンショットはその例です。 AVIFの4:2:0モード(色解像度を半分にする)はデフォルトにすべきではありません。ファイルサイズがほとんど減らず、より高い品質を達成するのが難しくなります。ただし、エンコードとデコードは速くなります。両方をチェックする時間がない場合は、4:4:4を使用してください。F1の画像はその一例であり、スクリーンショットはその例外です。 品質設定 すべてのエンコーダーで品質設定は信頼できます。単一の品質設定では、結果の品質は画像によって多少異なりますが、すべてのエンコーダーは同じ方向に変化し、妥当と思われる方法で変化します。データの例を参照してください。 プログレッシブJPEG XL プログレッシブJPEG XLは、高試行設定では基本的に無料です。jixelは最近、早期プログレッシブプレビューのサポートを追加し、最も遅い設定ではほとんどコストがかかりませんが、デフォルト設定ではファイルが12%大きくなります。FirefoxとChromeはプログレッシブJPEG XLをサポートしています。Safariはまだ最終画像をレンダリングしますが、プログレッシブプレビューは表示しません。しかし、この種のプログレッシブレンダリングはユーザーエクスペリエンスとして良いのでしょうか?例とデータを参照してください。 プログレッシブAVIF AVIFはプログレッシブレンダリングをサポートしています!現在はChromeのみですが、Firefoxでも開発中です。プログレッシブJPEG XLよりも複雑ですが、プレビューの外観をより細かく制御でき、ファイルサイズは通常小さく、デコードもはるかに高速です。ご自身で確認してください。 HDR HDRの場合、JPEG XLはゲインマップを欠いており、AVIFと比較して重大な制限となります。JPEG XLフォーマットはゲインマップをサポートしていますが、ブラウザデコーダーではサポートされておらず、エンコードの話は複雑で実験的です。ゲインマップを使用しないHDRコンテンツを比較すると、使用した2つの品質メトリックは大きく意見が分かれますが、JPEG XLがAVIFと比較してファイルサイズが小さいという点では一致しています。例を参照してください。 既存JPEGの圧縮 JPEG XLは、さらなる損失なしに、既存のJPEGを9~20%小さくすることができます。小さな画像を除いて、デコード速度も同等かそれ以上です。データを参照してください。 ロスレス ロスレスの場合、JPEG XLが明確な勝者です。ロスレスWebPは写真で9~17%大きく、ロスレスAVIFは30~120%大きくなります。しかし、ロスレス画像はウェブ上ではほとんど望まれません。もしウェブ上でそれらを使用する場合(このページで私がそうしているように)、jixelの高試行設定には注意してください。デコードに時間がかかりすぎるファイルを生成することがよくあります。データを参照してください。 アニメーション画像フォーマット アニメーション画像フォーマットは、依然として愚かなアイデアです。使用しないでください。必要であれば、もっと学んでください。 推奨事項 ウェブ利用のケースでは、現時点ではAVIF 4:4:4を、手間をかけられる最大の試行レベルで使用することをデフォルトにします。AVIFが異常に大きなファイルを生成していると感じた場合は、jixel経由でJPEG XLを確認し、それがより良い結果をもたらすかどうかを確認します。AVIFとJPEG XL(jixel経由)の両方が最近大幅に改善されたため、この推奨事項は将来変更される可能性があります。この件に関しては多くの誤情報があり、AIは喜んでその誤情報を配信します。代わりに、あなた自身の画像でテストしてください。AVIF関係者は、JPEG XLはAVIFと比較して技術的に制限されていると示唆しています。それは真実かもしれませんが、この記事では今日の実装結果に焦点を当てています。 方法論 私は、さまざまな設定でさまざまなコーデックを使用して画像をエンコードし、さまざまな詳細を記録するベンチマークスクリプトを「作成」しました。画像コーデックの最新リリースバージョンを使用しています。執筆時点では次のとおりです。 avifenc 1.4.2 libjxl 0.12.0(cjxlエンコーダーを使用) jixel 0.4.2(git f487299)、2番目のJPEG XLエンコーダー cwebp 1.6.0(ロスレスWebPは記事の後半で使用) 画像の選択を行い、ほとんどを幅1598ピクセルにエンコードしました。これはこのブログに表示される画像の最大幅の2倍です。これにより、ほとんどのユーザーが持っている高密度ディスプレイでシャープに見えます。その結果、小さな画面や低密度画面でこれを見ている場合、完全な体験は得られません。これらのベンチマークは、私の2024年製MacBook Pro(M4 Pro)で実行しました。 ロスあり - F1画像 ロスレスSSIMULACRA2ターゲット: 70(高) 5060708090 フォーマット AVIF 41.4 kB SSIMULACRA2: 70.2 JPEG XL (libjxl) 58.4 kB (+41%) SSIMULACRA2: 70.0 JPEG XL (jixel) 46.6 kB (+12%) SSIMULACRA2: 70.0 私が最初にAVIFについて書いたとき、最初の画像としてF1カーを使用しました。今回もそうすることにしました!さまざまなコーデック品質で画像をエンコードし、特定のSSIMULACRA2スコアに最も近いバージョンを選択しました。これは、JPEG XLの開発者による知覚画像品質メトリックです。50は中程度の品質、70は高、80は非常に高、90は視覚的にロスレスと見なされます。ただし、これらの評価が高密度ディスプレイを考慮しているかは定かではありません。記事全体を通して、上記の視覚的な比較では、各エンコーダーの最大試行設定を使用していますが、最大試行設定でファイルサイズが大きくなる場合(はい、そのようなこともあります)は例外です。アーカイブ用には、ほぼロスレスの品質を好みますが、ブログに説明用の画像を表示するだけであれば、パフォーマンスの方が私にとって重要です。私は個人的に上記の70の結果に満足しています。ズームインすると品質の低下が見えますが、ズームインケースを本当に気にするなら、VisualViewport APIのようなものを使用して、その場合に高解像度画像を読み込むのではなく、すべての人にとってダウンロードサイズを大きくするのではなく、そのような対応をします。低品質では、コーデック間の戦略の違いが見られます。ディテールの損失はほぼ同じですが、AVIFはオリジナルと比較して物事を滑らかにする傾向があるのに対し、JPEG XLはより粗いパターンを導入するようです。また、中程度の品質(50)では、AVIFとlibjxlはjixelバージョンよりも良く見えると感じます。jixelバージョンではBWTロゴの周りに多くの可視ノイズがあり、フロントウィングのMicrosoftのテキストははるかに読みにくくなっています。これはメトリックについて少し疑問に思わせます。いずれにせよ、結果に対する私の解釈は次のとおりです。 ファイルサイズ: AVIFの勝利。デフォルト設定では、最高のJPEG XL画像は...