WebP ファイル検査ツール

使い方

1. .webp ファイルをボックスにドロップします。写真、透明を含むステッカー、アニメーション、壊れていそうなファイル、どれでも構いません。
2. まずファイルの形を見ます。シンプル非可逆、シンプル可逆、拡張は別々のレイアウトで、シンプル形式しか知らないデコーダーは拡張を拒否します。
3. 宣言されたキャンバスと、このブラウザーがデコードしたサイズを比べます。一致するのが正常で、拒否された場合は検出された点に理由が出ます。
4. チャンク表でレイアウトを確認します。fourcc、オフセット、宣言サイズ、パッドバイトの有無が並びます。エンコーダーを調べるならここが出発点です。
5. アニメーションならフレーム表を見ます。オフセットは半分のフィールドから戻した実座標で、0ms のフレームは Chrome では 100ms で再生されます。

よくある質問

ある .webp は VP8 チャンクで始まり、別のものは VP8L や VP8X で始まります。同じフォーマットですか。

コンテナと拡張子は共通ですが、ビットストリームは別物です。シンプル非可逆形式は VP8 キーフレームを一つ包んでおり、これは VP8 動画の先頭に来るイントラフレームと同じものです。シンプル可逆形式は VP8L ストリームを包みますが、こちらは独自のエントロピー符号化と色変換を持つまったく別のコーデックです。拡張形式は VP8X チャンクを先頭に置き、別チャンク ALPH のアルファ、ICC プロファイル、Exif、XMP、アニメーションまで運べるようにしたうえで画像データを置きます。古いデコーダーがある WebP は開けて次は拒否するのはこのためで、シンプル形式は 2010 年、拡張形式は 2011 年に登場し、ライブラリごとに対応時期が違いました。どの形かを決めるのは最初のチャンクの fourcc だけです。

アニメーションのフレームオフセットが本来の半分に見えます。なぜですか。

文字どおり半分が格納されているからです。ANMF ヘッダーはフレームの X と Y を、実際のオフセットを 2 で割った 24 ビット値として持ちます。だからフレームは偶数座標にしか置けません。フィールドをそのまま表示する読み手は x=8 のフレームを x=4 と見せ、生の値を使う合成器はすべてのフレームをキャンバス端から半分の距離に描きます。はっきりした破綻ではなく、微妙にずれているように見えるバグです。同じヘッダーは幅と高さも −1 で格納するので、幅 32 ピクセルのフレームは 31 と書かれます。このツールはオフセットを 2 倍にし、サイズに 1 を足してから表示するので、ここの数値はデコーダーが実際に描く位置と一致します。

表示時間 0ms を宣言したフレームはどうなりますか。

ゼロ秒で消えるわけではありません。Chrome をはじめとする Blink 系ブラウザーは、WebP フレームの表示時間が 0 のとき 100ms を代わりに使います。ごく短い遅延を持つ GIF フレームへの扱いと同じで、0 は無限に速いアニメーションの要求ではなく書き間違いだとみなす発想です。Firefox と Safari が常に同じ判断をしてきたわけではなく、ffmpeg のようなコマンドラインツールは 0 をそのまま残して別のフレームレートを作ります。つまり宣言された表示時間の合計は実際の再生時間ではありません。このツールは両方の合計を出すので、タイミングに頼る前に差を確認できます。

キャンバスと中の画像のサイズが違います。ブラウザーは引き伸ばすのですか、レターボックスにするのですか。

静止画ではどちらでもありません。libwebp は VP8X のキャンバスが中の VP8 または VP8L フレームの寸法と一致することを要求し、食い違えばファイルを拒否します。Chrome も Firefox も Safari も libwebp で WebP をデコードするので、寸法の合わない静止画はどこでも表示されません。アニメーションでは規則が違い、キャンバスが大きくても構いません。各 ANMF フレームは自分のオフセットで合成され、キャンバスからはみ出した部分は切り取られます。だからこのツールは静止画のキャンバスとビットストリームの不一致を検出事項として報告し、キャンバスをはみ出すフレームは別に知らせます。

再生できるなら RIFF サイズフィールドはなぜ重要なのですか。

そのフィールドが正しいときにだけ再生できます。オフセット 4 の 4 バイトはファイルサイズから 8 を引いた値でなければならず(その 8 は RIFF の fourcc とサイズフィールド自身です)、libwebp はデコードの前にこれを検証します。途中で切れたダウンロードは元のサイズフィールドを保ったまま末尾のバイトを失うので、フィールドが大きすぎることになり、壊れた画像アイコン以外に何のメッセージもなく拒否されます。逆のケースは、メタデータを追記した後にフィールドを書き直し忘れたエンコーダーで、一部のツールでは読めてもブラウザーでは読めないファイルができます。このツールは両方の数値を出してどちらかを示し、最後のチャンクより後ろに残るバイトも別に表示します。

透明度はどう保存され、同じ絵でも ALPH チャンクがある場合とない場合があるのはなぜですか。

方式が三つあります。可逆ファイルはアルファを VP8L ストリーム自体に記録し、ヘッダーのヒントビットを立てるだけです。非可逆ファイルは VP8 にアルファチャンネルそのものがないためそれができず、拡張ファイルを作ります。アルファフラグを立てた VP8X、アルファ平面を持つ ALPH チャンク(可逆で圧縮し、必要なら水平・垂直・勾配のフィルターをかけます)、そして色を持つ VP8 チャンクです。アニメーションはこれをフレームごとに繰り返すので、ALPH を持つフレームと持たないフレームが混在します。もう一つ知っておくとよいのは、非可逆エンコーダーが容量を節約するために完全透明ピクセルの色を捨てるのが普通だという点です。合成やぼかしをかけるまで気づきませんが、libwebp の exact オプションがその色を保ちます。

関連ツール