Dark_Shikari、WebPについて語る

Diary Of An x264 Developer » H.264 and VP8 for still image coding: WebP?

H.264のエンコーダー、x264の開発者の一人である、Dark_Shikari氏が、WebPについて語っている。基本的に、WebP規格自体は悪くないのだが、公式のエンコーダーであるlibvpxがクソすぎる。

Dark_Shikari本人曰く、まだ追記するかもしれないとのこと。今は完全に一致しているが、念のためリンク先の翻訳元（英語）を参照することをおすすめする。

JPEGはかなり昔の圧縮フォーマットで、あまりよろしくない。実際のところ、MPEG-2時代の動画フォーマットですら、JPEGには勝てる。なぜ皆が移行しないのかというのは、単純だ。特に利点がないからだ。たとえJPEGより2倍すぐれていたとしても、全世界に対して、20年間使い慣れた画像フォーマットを変更するように強いるのは、不可能だ。さらに、JPEGは高速で、簡単で、事実上、特許やロイヤリティなどがフリーである。JPEGの代替は、かつて何度も試みられた。まず、JPEG-2000、次にMicrosoftのJPEG XR。どちらも、JPEGを王座から引きずり下ろすことを試みた。どちらも、まったく歯が立たなかったのだが。

さて、Googleがまた性懲りもなく新しい画像フォーマットをだしてきたわけだ。"WebP"とかいう、いや待てよ。単なるVP8のイントラフレームじゃないか。この新しい画像フォーマットがJPEGより劣る理由が、すぐに挙げられる。JPEGの全機能をサポートしていないからだ。アルファチャンネル、ロスレスといった機能がサポートされていない。4:2:0 chroma subsamplingしかサポートしていないのだ。JPEGなら4:2:2や4:4:4までもサポートしているというのに。そもそも、Googleはこれらの機能を付け加えることに興味を示していないようである。

まあ、ともかく、これらのエンコーダーが、静止画に対してどれだけ圧縮できるかを試してみよう。すでに説明したように、VP8はH.264とほぼ同じ優秀なイントラ予測（intra prediction）を備えている。すでに説明した理由によって、H.264のイントラ圧縮（intra compression）は、非常に優れているのだ。VP8はi4x4とi16x16モードしかなく、i8x8を持たないので、H.264ほどではないが、ほぼ同じ性能である。

訳注：ここでDark_Shikariが行っているテストとは、H.264とVP8で、1フレームだけエンコードすることによって、静止画圧縮を実現している。これは、H.264とVP8のイントラフレームの性能を比較しているのに等しい。イントラフレームは、単体でデコードできるため、静止画の圧縮フォーマットとしても流用可能である。WebPも、VP8のイントラフーレムを使っているに過ぎない。また、x264とはH.264のエンコーダー、libvpxとはGoogleによるVP8のエンコーダーである。jpgcrushとは、すでにエンコードされたjpegファイル自体を最適化するperlスクリプトである。これは、x264の開発者の一人である、Loren Merrittによって書かれた。最適化はロスレスで行われる。基本的な仕組みとしては、ある状態をjpegフォーマットでコードする方法は複数あり、そのうち最適なものを複数回の試行により選ぶものである。だからロスレスで最適化できる。

テストファイルは、すべて155KB程度である。ダウンロードして確かめるとよい。どのファイルに対しても、私はファイルサイズをほぼ同じにするためのクオリティレベルを。バイナリサーチして弾きだした。x264では、--tune stillimage --preset placeboでエンコードした。livpxでは、--bestでエンコードした。JPEGには、ffmpegを使い、さらにjpgcrushという、ロスレスのjpeg圧縮ツールを用いた。ひょっとしたら、ffmpegより優れたJPEGエンコーダーがあるかもしれない。もし読者が聡明にも、より優れたエンコーダーを知っていたならば、どうぞ自分でも試してもらいたい。画像のソースは、Xiph.org :: Test Mediaによる、Parkjoyの200フーレム目である。

ファイル：x264[154KB]、VP8[155KB]、jpg[156KB]

訳注：このファイルは、H.264とVP8のRaw streamである。このファイルをデコードして見るためには、ffmpegやmplayerなどを使うといい。

結果（デコードしてPNGに圧縮）：x264、VP8、jpg

訳注：このファイルは、エンコードされたファイルを一度デコードして、PNGに圧縮しなおしたものである。PNGはロスレス圧縮なので、単に画質を目で比較したい場合は、こちらをダウンロードするとよい。

これを見るとどうも、libvpxは赤面ものの結果になっている。主観的に思うに、VP8は最悪である。JPEGはブロッキングノイズがあるとはいえ、VP8よりマシである。何故こうなったのか？　VP8には、JPEGよりはるかに優れたエントロピーコーディング（entropy coding）があるというのに。VP8には、より優れたイントラ予測（intra prediction）があるというのに。JPEGにあるのはDC予測（DC prediction）だけだ。なぜVP8がこんなにも劣って見えるのか？　分析してみよう。

VP8は4×4変換（4×4 transform）を使っている。これは一般に、JPEGの8×8変換（8×8 transform）より、ブラーがかかり、細部が失われてしまう。しかし、それだけではここまで酷い違いにはならないはずだ。私の仮説では、おそらく問題は、libvpxの画像のエンコードでは、PSNRに最適化されていて、人間の目とっての高画質を無視しているのだ。ここで、x264を、--tune psnr --preset placeboでエンコードしてみよう、つまり、psy optimizationを無効にするのだ。

訳注：PSNRは、二つの画像を比較して、どのくらい違っているかを図るための、計算方法である。つまり、PSNRを計算することは、エンコードにより画像がどのくらい変化したかという、劣化具合を計算することができる。しかし、PSNRで高得点を得たからといって、必ずしも人間の目にとって、高画質であるとは限らない。x264には、psy optimizationという名称の、より人間的な画質の劣化具合を計算するための比較方法が実装されている。

ファイル：x264、PSNR最適化[154KB]、ちなみに、adaptive quantizationが無効になっているため、ファイルサイズを合わせるために、CQMを使った。

結果（デコードしてPNG圧縮）：x264、PSNR最適化

何というブラーだ！　VP8より多少はマシなだけである。JPEGより遥かに悪い。これが同じエンコーダーに、同じ品質の解析をさせた結果である。ただ唯一の違いは、psy optimizationを無効にしているだけである。

さて、ここで当然の疑問が沸き起こる。Googleはアホなのか？　JPEGより優れているのならば、WebPとやらをプッシュするのも分かる。もちろん、技術的に、ファイルフォーマットとしては、優れている。フォーマットに基づくエンコーダーも、JPEGより優れたものを出力できるであろう。ただし、「できるであろう」ということに注意しなければならない。なぜlibvpxが、未だにクソエンコーダーであるこの時期に発表するんだ？　こんなブラーだらけのクソでJPEGを置き換えるというのか？

全世界よりGoogleに告ぐ：まず、てめぇのエンコーダーをまともにしやがれ。代替案として宣伝するのはその後だ。順番が逆ではダメだ。

追記：
maikmertenがtheoraによる比較をしてくれた。PNGとソース。何と、Theora 1.2 (Ptalarbvorm) がVP8を打ち負かしているではないか。生き恥もいいところだな。Ptalarbvormの謳い文句の新機能とは何か。psy optimizationだよ。

ちなみに、以前にも、Dark_Shikari氏と、H.264のイントラフレームを、静止画のフォーマットとして流用することの如何をチャットしたことがある。H.264のイントラフレームを静止画のフォーマットとして使うにあたって、技術的な障害は何もないのだが、やはりすでに普及しているJPEGの牙城を崩すことは難しいだろう。現代では、画像程度のファイルサイズを、あまり気にしないという問題もある。画質はそのままで圧縮率が二倍になったとしても、テラバイトの3.5インチHDDが民生品として売っている現状では、あまり利点はない。

また、WebPは、weppy（ウェッピー）と読むらしい。bが無声音になるらしい。しかもy音が追加される。ふしぎふしぎ。最初、読み方はWeb-Pee（Web小便）かと思った。

追記：Chromium Blog: WebP, a new image format for the Webによれば、将来的にアルファチャンネルをサポートする意思はあるらしい。