Google は元々、JPEG に代わる非可逆画像形式として WebP を開発しました。JPEG では、JPEG としてエンコードされた同等品質の画像ファイルよりも小さいサイズのファイルを生成できます。その後のこの形式の更新では、可逆圧縮、PNG のようなアルファ チャンネル透明度、GIF のようなアニメーションのオプションが導入されました。これらはすべて、JPEG スタイルの非可逆圧縮と併用できます。WebP は信じられないほど汎用性の高い形式です。
WebP の非可逆圧縮アルゴリズムは、VP8 動画コーデックが動画のキーフレームを圧縮するために使用する方法に基づいています。大まかに言えば、JPEG エンコードに似ています。WebP は個々のピクセルではなく「ブロック」を基準として動作し、輝度と色差は同様に分割されます。WebP の輝度ブロックは 16x16 で、クロマブロックは 8x8 で、それらの「マクロブロック」はさらに 4x4 のサブブロックに細分化されます。
WebP が JPEG と根本的に異なるのに対し、「ブロック予測」と「適応型ブロック量子化」という 2 つの機能があります。
ブロック予測
ブロック予測は、各色差ブロックと輝度ブロックのコンテンツを、周囲のブロック（具体的には現在のブロックの上と左にあるブロック）の値に基づいて予測するプロセスです。ご想像のとおり、この処理を行うアルゴリズムはかなり複雑ですが、わかりやすい言葉で言うと、「現在のブロックの上に青色、現在のブロックの左側に青色がある場合、このブロックは青色であると仮定します」です。
実際、PNG と JPEG はどちらもある程度はこの種の予測を行います。ただし、WebP は周囲のブロックのデータをサンプリングし、いくつかの異なる「予測モード」を使用して現在のブロックへのデータ入力を試み、画像の欠落している部分を効果的に「描画」する点で独自性があります。各予測モードによって提供される結果が実際の画像データと比較され、最も近い予測一致が選択されます。
もちろん、最も近い予測マッチであっても完全に正しいとは限りません。そのため、そのブロックの予測値と実際の値の差がファイルにエンコードされます。画像をデコードするとき、レンダリング エンジンは同じデータを使用して同じ予測ロジックを適用するため、各ブロックで同じ予測値が得られます。予測とファイルにエンコードされた想定画像の差分が予測に適用されます。これは、ファイルの新しいコピーではなく、ローカル ファイルに適用される差分パッチを Git commit が表すのに似ています。
説明のため、真の予測アルゴリズムに関連する複雑な計算を掘り下げるのではなく、単一の予測モードを持つ WebP のようなエンコードを考案し、それを使用して、以前の形式と同じように数値のグリッドを効率的に中継します。このアルゴリズムには 1 つの予測モードがあり、これを「予測モード 1」と呼びます。各ブロックの値は、その上と左にあるブロックの値の合計で、1 から始まります。
次の実際の画像データから始めるとします。
111151111
122456389
予測モデルを使用して 2x9 グリッドの内容を特定すると、次のような結果になります。
111111111
123456789
当社のデータは Google が発明した予測アルゴリズムに適しており、予測データは実際のデータにほぼ一致します。 もちろん、完全に適合するわけではありません。実際のデータには、予測データとは異なるブロックがいくつかあります。したがって、送信するエンコードには、使用する予測方法だけでなく、予測値と異なるブロックの差分も含まれます。
_ _ _ _ +4 _ _ _ _
_ _ -1 _ _ _ -4 _ _
これまでに説明した以前の形式のエンコードと同じ種類のプレーンな言語を入力します。
予測モード 1 を使用した 2x9 グリッド+4 ～ 1x5、-1 ～ 2x3、-4 ～ 2x7。
その結果、驚くほど効率的にエンコードされたファイルが完成しました。
適応型ブロック量子化
JPEG 圧縮は包括的な処理であり、画像内のすべてのブロックに同じレベルの量子化を適用します。均一な構図の画像でもそれは理にかなっていますが、実際の写真は私たちを取り巻く世界と同じくらい均一ではありません。実際には、JPEG の圧縮設定は、JPEG 圧縮が優れている点の高頻度の詳細ではなく、画像内で圧縮アーティファクトが発生する可能性が最も高い部分によって決まります。
この誇張された例からわかるように、前景のオオカバマダラの翼は比較的鮮明に見えます。高解像度の元の画像と比べるとやや粗くなりますが、元の画像と比べると目立ちません。同様に、トウモロコシの詳細な花序と前景の葉では、訓練された目で圧縮アーティファクトの痕跡が見られるかもしれませんが、前景では妥当なレベルをはるかに超えて圧縮したとしても、かなり鮮明に見えます。画像の左上に表示される低周波の情報（葉の緑の背景はぼやけている）は、極めて劣悪に見えます。トレーニングを受けていない視聴者でも、すぐに品質の問題に気づくでしょう。背景の微妙なグラデーションは、ギザギザの無地のブロックに丸められます。
これを回避するために、WebP は量子化に適応型アプローチを採用しています。画像は最大 4 つの視覚的に類似したセグメントに分割され、それらのセグメントの圧縮パラメータは個別にチューニングされます。WebP で同じサイズ超過の圧縮を使用すると、次のようになります。
これらの画像ファイルのサイズはほぼ同じです。君主の翼を見ると、品質はほぼ同じです。非常によく見ると、最終的な結果にわずかな違いが見つかることがありますが、全体的な品質に実質的な違いはありません。WebP では、トウモロコシの花はわずか鋭くなっています。これもまた、我々のように両者を比較し、品質の違いを真に探さない限り、目立たせるには十分ではないでしょう。背景はまったく異なります。JPEG の明らかに明らかなアーティファクトの痕跡はほとんどありません。WebP は同じファイルサイズですが、はるかに高品質の画像を提供します。これら 2 つをそれほど密接に比較しなければ、心理視覚的システムは検出できないいくつかの細かいディテールが加わります。
WebP の使用
WebP の内部は JPEG エンコードよりもかなり複雑かもしれませんが、日常業務では同じくらいシンプルです。WebP のエンコードの複雑さはすべて、JPEG と同様に 0 ～ 100 で表現される単一の「品質」値で標準化されています。繰り返しになりますが、これはユーザーが 1 つの包括的な「品質」設定に制限されているというわけではありません。通常は目に見えない設定がファイルサイズと品質に与える影響についてよりよく理解するために、WebP エンコードのあらゆる細かな調整に取り組むことは可能です。
Google では、個々のファイルまたは画像のディレクトリ全体を変換または圧縮できる cwebp コマンドライン エンコーダを提供しています。
$ cwebp -q 80 butterfly.jpg -o butterfly.webp
Saving file 'butterfly.webp'
File: butterfly.jpg
Dimension: 1676 x 1418
Output: 208418 bytes Y-U-V-All-PSNR 41.00 43.99 44.95 41.87 dB
(0.70 bpp)
block count: intra4: 7644 (81.80%)
Intra16: 1701 (18.20%)
Skipped: 63 (0.67%)
bytes used: header: 249 (0.1%)
mode-partition: 36885 (17.7%)
Residuals bytes |segment 1|segment 2|segment 3|segment 4| total
macroblocks: | 8%| 22%| 26%| 44%| 9345
quantizer: | 27 | 25 | 21 | 13 |
filter level: | 8 | 6 | 19 | 16 |
コマンドラインを使う傾向がない場合は、Squoosh が WebP のエンコードにも同様に役立ちます。さまざまなエンコード、設定、品質レベル、JPEG エンコードとファイルサイズの違いを並べて比較できます。