Jyrki Alakuijala 博士、Google, Inc.
Vincent Rabaud 博士、Google, Inc.
最終更新日: 2017-08-01
要約 -- 可逆モードと非可逆モードの両方で、WebP エンコーダ/デコーダのリソース使用量と PNG のリソース使用量を比較します。ウェブからランダムに選択された 12,000 個の半透明の PNG 画像から成るコーパスを使用し、シンプルな測定値を使用してパフォーマンスの変化を示します。WebP 画像をサイズ最適化 PNG と比較するため、コーパス内の PNG を再圧縮しました。その結果、サイズと処理速度の点で、WebP がウェブで使用する PNG の代わりに最適であることがわかりました。
はじめに
WebP は可逆圧縮と半透明の画像をサポートしているため、PNG 形式に代わるものです。辞書コーディング、ハフマン コーディング、カラー インデックス変換など、PNG 圧縮で使用される基本的な手法の多くが WebP でもサポートされているため、最悪の場合も速度と圧縮密度はほぼ同じになります。同時に、さまざまなカラー チャネルの個別のエントロピー コード、後方参照距離の 2D 局所性、最近使用された色のカラー キャッシュなど、多くの新機能により、ほとんどの画像で圧縮密度の向上が実現しています。
この作業では、WebP のパフォーマンスと、pngcrush と ZopfliPNG を使用して高圧縮の PNG のパフォーマンスを比較します。ベスト プラクティスを使用してウェブ画像のリファレンス コーパスを再圧縮し、可逆圧縮と非可逆 WebP 圧縮の両方をこのコーパスと比較しました。速度とメモリ使用率のベンチマークを行うために、参照コーパスに加えて、2 つの大きな画像（1 つは写真、もう 1 つはグラフィック）を選択しました。
PNG よりも高速なデコード速度と、現在の PNG 形式で達成できる圧縮密度よりも 23% 高密度であることが実証されています。WebP は現在の PNG 画像形式のより効率的な代替であると結論付けられます。さらに、可逆アルファ サポートを備えた不可逆画像圧縮により、ウェブサイトの高速化の可能性がさらに広がります。
Methods
コマンドライン ツール
パフォーマンスを測定するために、次のコマンドライン ツールを使用します。
cwebp と dwebp です。libwebp ライブラリ（ヘッドからコンパイル）の一部であるツール。
表示されます。これは、ImageMagick ソフトウェア（2017 年 7 月 21 日 6.7.7-10）のコマンドライン ツール部分です。
pngcrush 1.8.12（2017 年 7 月 30 日）
ZopfliPNG（2017 年 7 月 17 日）
コマンドライン ツールには、それぞれの制御フラグを指定します。たとえば、cwebp -q 1 -m 0 を参照する場合、cwebp ツールが -q 1 フラグと -m 0 フラグで呼び出されたことを意味します。
画像のコーパス
次の 3 つのコーパスが選ばれました。
単一の写真画像（図 1）
半透明度の単一のグラフィック画像（図 2）
ウェブコーパス: インターネットからクロールされた、ランダムに選択された 12,000 個の PNG 画像（半透明かどうかなど）。これらの PNG 画像は、convert、pngcrush、ZopfliPNG で最適化され、各画像の最小バージョンが考慮されます。
図 1. 写真画像、1024 x 752 ピクセル。火の呼吸 「Jaipur Maharaja Brass Band」、Chassepierre ベルギー、著者: Luc Viatour、写真、クリエイティブ・コモンズ表示 - 継承 3.0 非移植ライセンス。著者のウェブサイトはこちらです。
図 2. 1024 x 752 ピクセルのグラフィカル画像。Google グラフツールのコラージュ画像
既存の形式である PNG の機能をすべて測定するために、次のように元の PNG 画像をすべて再圧縮しました。
コンポーネントあたり 8 ビットに固定: input.png -depth 8 output.png
予測子のない ImageMagick(1): input.png -quality 90 output-candidate.png
適応型予測子を備えた ImageMagick: input.png -quality 95 output-candidate.png
Pngcrush(2): pngcrush -brute -rem tEXt -rem tIME -rem iTXt -rem zTXt -rem gAMA -rem cHRM -rem iCCP -rem sRGB -rem alla -rem text input.png output-candi
ZopfliPNG(3): zopflipng --lossy_transparency input.png output-candidate.png
すべてのフィルタを含む ZopfliPNG: zopflipng --iterations=500 --filters=01234mepb --lossy_8bit --lossy_transparency input.png output-candidate.png
結果
ウェブコーパスの各画像の圧縮密度は、次の 3 つの方法で最適化された PNG 画像サイズと比較して算出しました。
WebP ロスレス（デフォルト設定）
最小サイズの WebP ロスレス（-m 6 -q 100）
WebP 可逆圧縮と WebP 非可逆圧縮の優れた点（デフォルト設定）です。
これらの圧縮係数を並べ替えて、図 3 にプロットしました。
図 3. 基準として PNG 圧縮密度を 1.0 としています。同じ画像が、可逆圧縮と非可逆圧縮の両方で圧縮されます。画像ごとに、圧縮 PNG に対するサイズ比率が計算され、サイズ比率が並べ替えられ、可逆圧縮と非可逆圧縮の両方で表示されます。非可逆圧縮曲線では、小さい WebP 画像が生成される場合に可逆圧縮が選択されます。
WebP は、最高品質の libpng（変換）と ZopfliPNG（表 1）の両方で PNG 圧縮密度を上回り、エンコード（表 2）とデコード（表 3）の速度は PNG とおおむね同等です。
表 1. 異なる圧縮方法を使用した 3 つのコーパスのピクセルあたりの平均ビット数。
| 画像セット | コンバージョン -品質 95 | ZopfliPNG | WebP ロスレス -q 0 -m 1 | WebP ロスレス（デフォルト設定） | WebP ロスレス -m 6 -q 100 | WebP 不可逆圧縮（アルファあり） |
|---|---|---|---|---|---|---|
| 写真 | 12.3 | 12.2 | 10.5 | 10.1 | 9.83 | 0.81 |
| 刺激の強い ; 不適切な（# など、文脈や文書内での統一性に応じて） | 1.36 | 1.05 | 0.88 | 0.71 | 0.70 | 0.51 |
| ウェブ | 6.85 | 5.05 | 4.42 | 4.04 | 3.96 | 1.92 |
表 2. 圧縮コーパスとさまざまな圧縮方法の平均エンコード時間。
| 画像セット | コンバージョン -品質 95 | ZopfliPNG | WebP ロスレス -q 0 -m 1 | WebP ロスレス（デフォルト設定） | WebP ロスレス -m 6 -q 100 | WebP 不可逆圧縮（アルファあり） |
|---|---|---|---|---|---|---|
| 写真 | 0.500 秒 | 8.7 秒 | 0.293 秒 | 0.780 秒 | 8.440 秒 | 0.111 秒 |
| 刺激の強い ; 不適切な（# など、文脈や文書内での統一性に応じて） | 0.179 秒 | 14.0 秒 | 0.065 秒 | 0.140 秒 | 3.510 秒 | 0.184 秒 |
| ウェブ | 0.040 秒 | 1.55 秒 | 0.017 秒 | 0.072 秒 | 2.454 秒 | 0.020 秒 |
表 3: 異なるメソッドと設定で圧縮された画像ファイルの 3 つのコーパスの平均デコード時間。
| 画像セット | コンバージョン -品質 95 | ZopfliPNG | WebP ロスレス -q 0 -m 1 | WebP ロスレス（デフォルト設定） | WebP ロスレス -m 6 -q 100 | WebP 不可逆圧縮（アルファあり） |
|---|---|---|---|---|---|---|
| 写真 | 0.027 秒 | 0.026 秒 | 0.027 秒 | 0.026 秒 | 0.027 | 0.012 秒 |
| グラフィック | 0.049 秒 | 0.015 秒 | 0.005 秒 | 0.005 秒 | 0.003 | 0.010 秒 |
| ウェブ | 0.007 秒 | 0.005 秒 | 0.003 秒 | 0.003 秒 | 0.003 | 0.003 秒 |
メモリ プロファイリング
メモリ プロファイリングでは、/usr/bin/time -v で報告されるレジデント セットの最大サイズを記録しました。
ウェブコーパスの場合は、最大の画像のサイズだけで最大メモリ使用量が決まります。メモリ測定をより明確に定義するために、1 枚の写真画像（図 1）を使用してメモリ使用量の概要を示します。グラフィカルな画像でも同様の結果が得られます。
-q 0 -m 1 と -q 95（デフォルト値は -m）でそれぞれ設定し、libpng と ZopfliPNG で 10 ～ 19 MiB、WebP ロスレス エンコードで 25 MiB と 32 MiB を測定しました。
デコード テストで「convert -resize 1x1」を実行すると、libpng と ZopfliPNG で生成される PNG ファイルの両方に 10 MiB が使用されます。cwebp を使用する場合、WebP の可逆デコードでは 7 MiB、非可逆デコードでは 3 MiB を使用します。
まとめ
エンコード速度とデコード速度は、どちらも PNG の同じドメインにあることがわかっています。エンコード フェーズでのメモリ使用量は増えますが、デコード フェーズでは少なくとも cwebp の動作を ImageMagick の変換の動作と比較すると健全に減少しています。
圧縮密度はウェブ画像の 99% 以上で優れており、PNG から WebP に比較的簡単に変更できることを意味しています。
デフォルト設定で WebP を実行すると、圧縮率が libpng より 42%、ZopfliPNG より 23% 優れています。このことは、WebP が画像の多いウェブサイトの高速化を期待していることを示唆しています。
参照
外部リンク
以下に示すのは、Google がスポンサーとなっていない独立した研究であり、Google が必ずしもすべてのコンテンツの正確性を立証しているわけではありません。