WebP技術の長所と短所の分析（2021）
(eng.aurelienpierre.com)- WordPressと主要ブラウザのWebP対応により写真ライブラリの移行は容易になったが、実写写真ではファイルサイズ削減よりもポスタリゼーションやリンギングのような劣化のほうが大きく目立つ
- Googleや複数のWordPressプラグインは、WebPはJPEGより小さく、
lossy 80で十分だと案内しているが、既存のJPEGを再びWebPに変換すると非可逆圧縮が累積する可能性がある - スタジオのポートレート写真やフィルムスキャンのようになめらかなグラデーションが重要な画像では、WebP 95〜96でもJPEG 85+ノイズと同程度か、それ以上に重い結果になる
- 平均SSIMと平均ファイルサイズの比較では、写真家に必要な最悪ケースへの対応は保証できず、画像ごとの品質調整が難しいWebサイトでは安定性のほうが重要である
- 画像品質が重要なサイトなら、JPEG 85〜90の維持、ディザリングや微細ノイズの追加、既存JPEGのWebP再エンコード回避、CDN・レスポンシブ画像・遅延読み込みの活用のほうが現実的である
WebP導入への期待と実際の問題
- WordPressが
image/webpMIMEタイプのアップロードを受け入れ、2020年9月以降は主要ブラウザでWebPを表示できるようになったことで、写真ライブラリをWebPへ移行しやすくなった - WebPは同じ品質ならJPEGより15%小さいという比較や、Googleが示す25〜34%小さいという数値によって、魅力的な選択肢に見える
- WordPressには既存のメディアライブラリをWebPへ変換するプラグインが多く、かなりの数が外部サーバーで変換するSaaS方式で動作する
- 一部のプラグインや技術文書では、WebP品質
lossy 80以上はほとんどの写真で不要だと案内しているが、ロゴの例では実際の写真作業の問題を十分に代表できていない
既存JPEGをWebPに再圧縮するときの劣化
lossy 80品質でWordPressのメディアを一括変換したところ、背景にポスタライズされたリングが現れた- 問題となった画像は、Ilford Delta 400フィルムをMamiya RB 67で撮影した6×7cmの中判フォーマットスキャンで、元データは16ビットスキャンから始まっている
- Delta 400の銀塩粒子は自然なディザリングのように働き、なめらかな領域のポスタリゼーションを防ぐのに有利だが、WebP変換後はグラデーションが階段状に崩れた
- 元のJPEG品質85も完全にクリーンではなかったが、WebP変換版よりは良好で、すでに非可逆圧縮されたJPEGの上にさらにWebPの非可逆圧縮を重ねた影響が大きい
- Google Page Speed Insightsや複数のプラグインは、このような再エンコードの流れを推奨したり容易にしたりしているが、実際の品質劣化を考えると安全ではない
実写写真での比較実験
- RAW写真をdarktableから直接エンコードして一度だけ圧縮する条件でも、WebPの弱点が確認された
- テスト画像は実際のスタジオヘッドショットで、なめらかに落ちる照明と背景のグラデーションが重要な写真である
- JPEGとWebPをともに品質90で保存し、8ビットのFloyd-Steinberg ditheringを適用した結果:
- JPEG 85とWebP 90はいずれも失敗と評価された
- WebPはポスタリゼーションリングのコントラストがより高く、さらに悪く見える
- WebP 90は推奨値
lossy 80より10ポイント高い品質であるにもかかわらず、問題が残った - JPEG 90は許容できる見た目だったが、ファイルサイズはより大きかった
- WebPを可逆圧縮で保存すると品質はきれいになったが、ファイルサイズは満足できず、JPEG 90はその約3分の1のサイズで見分けがつきにくく、JPEG 95も半分を少し超える程度のサイズで同様に見えた
- Floyd-Steinbergディザリングの代わりに-48 dB PSNRのランダムノイズを追加したテストでも、WebPは依然としてポスタリゼーションに弱かった
- JPEG 85+ノイズと同程度になめらかになるWebP品質は95〜96の間だった
- この条件でWebPはJPEG 85+ノイズより39%重く、JPEG 90+Floyd-Steinbergディザリングよりも30%重かった
- WebPの結果には依然として弱いリンギングが残った
平均指標と写真品質のギャップ
- WebPの優秀さの評価は、画像データセットの平均SSIMと平均ビットサイズに大きく依存している
- 平均値では、写真家がWebポートフォリオで求める出力の安定性を保証できない
- 写真ポートフォリオは、圧縮バックエンドがランダムに失敗してよい領域ではない
- 画像ごとにWebP品質を細かく調整する作業は時間がかかり、WordPressではそのような運用も難しいと考えられる
- SSIMは平均・分散・共分散に基づく画像類似度指標であり、実際の知覚メトリクスを十分に反映しないとして議論がある
- 圧縮劣化では、数値的な偏差の大きさだけでなくアーティファクトの性質が重要である
- ランダムノイズはある程度許容できる
- パターンのあるシミや段階状のグラデーションは写真をより深刻に損なう
WebPが特に弱いシーン
- 写真作業で最も厄介なシーンは、鮮明なディテールよりもなめらかなグラデーションであることが多い
- 壁に点光源に近い光が当たり自然な背景を作る状況では、背景は十分な質感を持ちながらも被写体から視線を奪わない必要がある
- WebP圧縮の例では、鮮鋭で被写界深度が深く、高周波ディテールの多いシーンがよく示されるが、このようなシーンはポスタリゼーションが起きにくく、アルゴリズムの弱点をうまく露呈しない
- シャープネス不足が写真を必ずしも台無しにするわけではないが、なめらかなビネットが階段状に崩れる現象は受け入れがたい劣化である
フォーマット設計と色の問題
- WebPはRGBまたはRGBalpha形式のため、モノクロ画像を単一チャネルのグレースケール画像として保存できない
- テストで見られたポスタリゼーションは、マゼンタとグリーンのリングによってさらに悪化しており、クロマサブサンプリングによる色ずれと解釈できる
- 純粋なモノクロ形式を単一チャネルで保存できれば、追加のクロマシフトを生じさせずに済む可能性がある
- AVIFはこの点を解決しているが、技術的に広く現実化するまでには少なくとも10年はかかると見られている
画像品質を守るための対応
- 画像が重要なWebサイト、特にビジュアルアーティストのポートフォリオなら、JPEG品質90、少なくとも85を維持するほうがよいと判断される
- なめらかなグラデーションを守るには、画像にディザリングまたはごく弱いノイズを常に追加する方法が勧められる
- 既存のJPEGはWebPに変換しないほうがよく、前述の例レベルの劣化を受け入れられる場合にだけ例外となる
- 読み込み速度と体感レスポンスを高めるには、フォーマット変換よりもCDN、レスポンシブ画像サイズ、画像の遅延読み込みを活用するほうが安全である
- 外部サーバーで変換するSaaS方式はコストがかかり、実際の品質係数を公開せず、セキュリティプラグインで強化されたWordPress環境などではHTTP接続エラーが発生することもある
- サーバー上で直接ImageMagickまたはGraphicsMagickを実行する方式のほうがよく、PHPインターフェースではなくサーバープログラムを直接使うアプローチが推奨される
- 技術開発者や画像アルゴリズム設計者が平均指標だけでフォーマット選択を押し進めると、実際のアーティストに時間とコストの損失を与える可能性がある
1件のコメント
Hacker News の意見
WebP でも同じ問題を見たので、ほとんど JPG/PNG に戻しました。写真には jpg、UI 系の画像には png を使っています。
本当の問題は、多くの人が違いに気づかないことにあるように思えますが、それはこの10年間、デスクトップモニターが革新のない死角に取り残されてきたためのようです。ここにいる半数は、2012年ごろに出た 1920x1080 の LCD でサンプル画像を見ているはずで、それも問題の一部です。
不思議なことに、スマートフォンのような小さな画面や 4K TV のような大きな画面は、視聴距離に対するピクセル密度が素晴らしくなった一方で、20〜40インチのパネルは2000年代半ばの水準に閉じ込められたままです。
また、筆者が明るい背景のサンプル写真を使うか、記事の背景を黒に変えていれば、もっとよかったと思います。白い背景の上に黒い画像があると目が順応しにくく、問題を見つけづらいですが、暗い背景に置くと差ははるかに見えやすくなります。
なので、ディスプレイ品質が核心的な問題だとは考えにくいです。ドライバや後処理フィルターの問題かもしれないし、単に誰もがこうしたものを見分ける目を持っているわけではないのかもしれません。
画像処理に関心があると、経験上こうしたディテールが見えるようになります。筆者は明らかに私より経験が豊富で、こうしたディテールを見ることが仕事の一部なのかもしれません。ひどいモニターでも問題を見抜き、そのモニターがどのようにひどいのかまで説明してくれる可能性が高いです。
例があまり良くありません。何かを見せたいなら、スクリーンショットを拡大してアーティファクトを示すべきです。
PNG を WebP に変えるとき、「lossless WebP」の lossless は実際にはロスレスではないのでしょうか？
参考までに、PNG をロスレス WebP に変換したあと再び PNG に展開し、その PNG をまた WebP に変換すると、完全に同じロスレス WebP ファイルになります。PNG から直接ロスレスエンコードしても、PNG 最適化ツールで「crush」した同じ PNG からエンコードしても、同じ WebP になります。
最良の結果に本当にこだわる人がいるのは良いことですが、大半の人は気づきもしないし気にもしないと思います。
最初の2枚の写真をそれぞれタブで開いて素早く切り替えてみたが、違いはまったくなかった。別々のモニター2台、ChromeとFirefoxで試し、最後の男性の写真でも同じだった。
修正: 最後の比較はWebPが2回入っていて、リンクが間違っていた。jpgはこちらだが、それでも差は見えない。
https://eng.aurelienpierre.com/wp-content/uploads/sites/8/20...
修正: 真実を見るには、実際にクリックしてフルサイズ画像を見る必要がある。本文に埋め込まれた画像は、可逆とされているものまで圧縮アーティファクトがかなりひどかった。
そのため、https://eng.aurelienpierre.com/wp-content/uploads/sites/8/20... のフルサイズ可逆WebPは問題なさそうに見えるが、同じ画像の埋め込み版である https://eng.aurelienpierre.com/wp-content/uploads/sites/8/20... はひどく見える。
修正2: 下の3つの差はかなり明白。
https://eng.aurelienpierre.com/wp-content/uploads/sites/8/20... lossy-noise.jpg (216 kB JPEG)
https://eng.aurelienpierre.com/wp-content/uploads/sites/8/20... (150 kB WebP)
https://eng.aurelienpierre.com/wp-content/uploads/sites/8/20... (301 kB WebP)
WebPの例はどちらも、301 kB版でさえポスタリゼーションがはっきり見える。
使用したWebPエンコーダーや設定に問題があるのではないかと気になる。
修正3: モニターのガンマとカラープロファイルは、グラデーションのポスタリゼーションの見えやすさに影響する可能性がある。
https://eng.aurelienpierre.com/wp-content/uploads/sites/8/20...
https://eng.aurelienpierre.com/wp-content/uploads/sites/8/20...
ただし写真に関心がなければ、見るほど気にしないかもしれない。
こうした差は小さくない。差が見えない人や、よく見ないと分からない人は、多くの人にはその差が即座に見えることを知っておくべきだ。
2枚目の画像はjpeg 90 [1]とwebp 90 [2]のバージョンを開いてみたが、両者を比較すると首の右側に明確なバンディングの問題がある。画像全体の周囲を回る暗めの帯も少し目立ちにくいが、どこを見るべきか分かっていればまだ見える。
jpeg 90をwebp lossless、jpeg 100、jpeg 95のいずれかと比較すると、首の右側にjpeg 90のごく弱いバンディングも見える。ただし拡大しなければ非常に分かりにくい。
[1] https://eng.aurelienpierre.com/wp-content/uploads/sites/8/20...
[2] https://eng.aurelienpierre.com/wp-content/uploads/sites/8/20...
私が思うに、WebP の最悪で最も見分けやすい欠点は、強制的な 4:2:0 クロマサブサンプリングだ。明るい色を含む多くの画像で、色と輝度の損失が専門的な目がなくてもはっきり見える
比較 [1] では右上の風船が鮮やかな赤を失っているのが明瞭で、比較 [2] では中央の明るい青いネオンアートが輝度を失っている
[1] https://storage.googleapis.com/demos.webmproject.org/webp/cm...
[2] https://storage.googleapis.com/demos.webmproject.org/webp/cm...
なぜこのコマンドが jpg > webp 変換で薄い青色を作り、他の色はそこそこ問題なく出るのか気になっている
cwebp -pass 10 -m 6 -nostrong -sharp_yuv -quiet -q 60 -sharpness 2 $1 -oこの記事は、私が WebP で最も大きく感じている問題を扱っていない。ブラウザの外でこの形式がもたらす 不便さは、小さな容量削減を上回る
より良い形式はいくつもある。HEIF、AVIF、H.266 から出てきうるような動画コーデックに着想を得た形式や JPEG XL もあり、WebP は十分な利点のない妥協案に見える
多くの人は、最良条件に近い WEBP 画像でバンディングが見えるか見えないかを議論しているが、現実の WEBP 画像はたいていひどく見える。私は最近になってようやく本格的に気づき始めた
もちろん今では生成 AI によるアップスケーリング工程で画像を「整理」できるが、誰かが 45KB を節約しようとしたせいで、これほど多くの電力を使うのはかなり皮肉だ
これは GIF が JPEG に変換されていた時代も思い出させる。25年ほど前には 256色で十分だったきれいな GIF スクリーンショットがたくさんあったのに、JPEG が台無しにした
Google は開発者に WEBP を使えと言うが、誰も見たがっていない動画広告をペタバイト単位で配信することには何の問題もない
「素人目には問題なさそうに見えるかもしれないが、写真家にはそうではない」というなら、WebP がなぜ悪いのかを「素人」に示し、記事とその論調を正当化するための、もっと良い例があるべきだと思う
Android で見ているせいか、どの写真も品質が同じに見える
それに「専門家の目」のために写真を作るなら、専門家の目に合わない技術を使わなければいいだけでは？ あるいは、そういう意思決定を他人に任せないことだ
このスレッドで、筆者がたわごとを言っていて違いはないと自信満々に言うコメントを見ていると、その苛立ちは正当だと思える。最初の画像群で違いが見えないのは構わないが、だからといって筆者よりよく分かっていると自信満々に言ったり、画像コーデックを設計したりすべきではない
全画面で見なくても分かった。しかめ面をした男性を見て、肩の近くのシャツの端を見ればいい
画質の悪い写真では、肩の周りにまるで逆光のような 光のにじみが生じている
画質の良い写真ではグラデーションが滑らかだ。肩の周りに逆光のような光のにじみはなく、ただ滑らかなグラデーション背景のように見える
はっきり言っておくと、私は写真家ではなく DevOps エンジニアだ。JavaScript を職業として最後に書いたのも少なくとも11年前だ
十分簡単に見える
[1] https://news.ycombinator.com/item?id=38653224
このブログ記事の基本発想全体が、形式間比較として基本的な検証を通ろうとしているのではなく、不満とクリックを増やそうとしているように見える
少し背景を説明すると、Aurelien Pierre は Darktable の主要コントリビューターとして知られている。Darktable はオープンソースの RAW 現像/カタログ管理ツール、つまりオープンソースの Adobe Lightroom のようなものだ
彼は正しいやり方について強い見解を持つことで知られており、時には荒っぽいほどで、Darktable を Ansel という自分のプロジェクトとしてフォークしたこともある。以前 HN での議論もあった https://news.ycombinator.com/item?id=38390914
アーカイブ画像の品質を気にするなら、非圧縮の元画像からできる場合でない限り、古い画像を新しい形式で再圧縮することはないでしょう。非可逆圧縮されたソースから再エンコードすると品質は悪くなります。ストレージは安く、今もさらに安くなり続けています。
意味があるのは、新しい写真を新しい形式で圧縮するときに安全な設定を選ぶことです。
この文脈でGoogleは、ChromeでのJPEG XLサポートを削除し、復活も拒否しながら、WebPのような既存形式と比べて「漸進的な利点」が十分ではないと主張し、JPEG XLを阻んできました。
-q100で目に見えるバンディングが出ますし、JPEGは-q90でも視覚的には透明です。筆者は焦点を当てる場所を間違えているように思います。形式の違いに注目していますが、実際には圧縮方式に注目すべきでした。画像処理プログラムごとに、同じ数値、たとえば「80」に設定しても圧縮結果は異なります。
本当に意味のある比較をするには、滑らかなグラデーション背景の白黒スタジオ人物写真だけでなく、複雑な背景を持つフルカラー画像など、さまざまな画像をテストする必要があります。imagemagik、graphicsMagick、sharp、photoshop、各種クラウドサービスのような複数のプログラムも併せて見るべきです。
もう一つの問題はユースケースです。プロの写真家がフルサイズ・最高品質の写真をアップロードしたいのであれば、創作・編集結果が完全に保存されるよう、単に圧縮しないほうがよい場合もあります。しかしそのユースケースは、Webサイトが適切なサイズと適切な品質の画像を表示するという平均的なユースケースではありません。
多くの状況では、ずっと小さい画像のために強めの圧縮を受け入れる価値がありますし、多くの画像では、大きなグラデーション背景を持つフル解像度のプロ向けスタジオ写真ほど圧縮が目立つことはないでしょう。
個人的には意味のある差が見えないので、私の目は確実に「素人の目」なのだと思います。
筆者が不満を述べているのは、画像の背景に生じたアーティファクトです。
知覚が人によってこれほど違うのは不思議です。
WebPのグラデーションは、しばしば動画の静止画のように見えます。クロマサブサンプリングは利用できる輝度近似値の密度を下げ、強く適用されるほどグラデーションは悪化します。
コントラストが高く高周波のディテールは大きな影響を受けませんが、グラデーションはひどく壊れることがあります。
クロマは色を意味し、色差サブサンプリングは、より重要な輝度チャンネルから情報を取り除かないために使われる方式です。