Jyrki Alakuijala 博士、Google, Inc.
Vincent Rabaud, Ph.D.、Google, Inc.
最終更新日: 2017 年 8 月 1 日
概要 -- WebP エンコーダ/デコーダのリソース使用量を、可逆モードと可逆モードの両方で PNG のリソース使用量と比較します。ウェブからランダムに選んだ 12,000 個の半透明 PNG 画像のコーパスを使用し、パフォーマンスの測定結果の変化を示す簡単な測定を行います。コーパス内で PNG を再圧縮して、WebP 画像とサイズ最適化 PNG を比較しています。結果から、WebP はサイズと処理速度の両方について、ウェブで PNG に置き換えるのに適していることを示しています。
はじめに
WebP は可逆画像と半透明画像に対応しており、PNG 形式に代わるものです。辞書コード、ハフマン コーディング、カラー インデックス変換など、PNG 圧縮で使用される基本的な技術の多くは WebP でもサポートされているため、最悪の場合、速度と圧縮密度は同程度になります。同時に、さまざまなカラーチャネルの個別のエントロピー コード、後方参照距離の 2D 局所性、最近使用された色のカラー キャッシュなど、いくつかの新機能によって、ほとんどの画像で圧縮密度を向上させることができます。
この作業では、pngcrush と ZopfliPNG を使用して、圧縮率の高い PNG とパフォーマンスの高い PNG のパフォーマンスを比較します。ベスト プラクティスを使用して、ウェブ画像の参照コーパスを再圧縮し、可逆圧縮と不可逆圧縮の WebP 圧縮をこのコーパスと比較しました。基準コーパスに加えて、2 つの大きな画像(1 つは写真用、もう 1 つはグラフィック)を速度とメモリ使用のベンチマーク用に選択しました。
PNG よりもデコード速度が速く、現在の PNG 形式よりも 23% 高い密度圧縮を実現しています。WebP は、今日の PNG 画像形式に代わる効率的な手段であるという結論に達しました。さらに、ロスレス アルファ サポートを使用したロッシー画像圧縮により、ウェブサイトの高速化をさらに実現できます。
Methods
コマンドライン ツール
パフォーマンスを測定するには、次のコマンドライン ツールを使用します。
cwebp と dwebp です。libwebp ライブラリの一部であるこれらのツール(ヘッドからコンパイル)。
コンバージョンこれは、ImageMagick ソフトウェアのコマンドライン ツール部分です(6.7.7-10 2017-07-21)。
pngcrush 1.8.12(2017 年 7 月 30 日)
ZopfliPNG(2017 年 7 月 17 日)
コマンドライン ツールと、それぞれのコントロール フラグを使用します。たとえば、cwebp -q 1 -m 0 を参照する場合、cwebp ツールが -q 1 フラグと -m 0 フラグで実行されたことを意味します。
画像コーパス
3 つのコーパスを選択しました。
単一の写真画像(図 1)
半透明のグラフィックの画像 1 枚(図 2)
ウェブコーパス: インターネットからクロールされた、ランダムに選択された 12,000 個の PNG 画像(半透明であるかどうかは不有)。これらの PNG 画像は変換、pngcrush、ZopfliPNG によって最適化され、各画像の最小バージョンが調査に使用されます。
図 1. 写真画像、1, 024 x 752 ピクセル。ファイヤー ブレス 「ジャイプル マハラジャ ブラスベルト」著者のウェブサイトはこちらをご覧ください。
図 2. グラフィック画像、1, 024 x 752 ピクセル。Google Chart Tools からのコラージュ画像
既存の 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 を変換する
PNG(2)
ZopfliPNG(3): zopflipng --lossy_transparency input.png output-candidate.png
{0/}
結果
3 つのメソッドについて、最適化された PNG 画像サイズを基準に、ウェブコーパス内の各画像の圧縮密度を計算しました。
WebP ロスレス(デフォルト設定)
最小サイズでの WebP ロスレス(-m 6 -q 100)
アルファあり(デフォルト設定)の WebP ロスレスと WebP 損失の長所。
これらの圧縮係数を並べ替え、図 3 にプロットしました。
図 3. PNG 圧縮の密度を基準として使用(1.0)。同じイメージが、ロスレスとロッシーの両方の方法で圧縮されます。画像ごとに、圧縮 PNG に対するサイズ比が計算され、サイズ比が並べ替えられ、ロスレス圧縮とロッシー圧縮の両方で表示されます。ロッシー圧縮曲線の場合、小さい WebP 画像を生成する場合はロスレス圧縮を選択します。
WebP は、libpng の圧縮密度を超えて最高品質(変換)と ZopfliPNG(表 1)の両方で実現され、エンコード(表 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 |
web | 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 秒 |
web | 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 秒 |
web | 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 でした。
デコードのテストでは、変換 - サイズ 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 は必ずしも、すべてのコンテンツの正確性を裏付けるものではありません。