cwebp
コマンドはGoogleが提供するWebP変換のためのコマンドで、JpegやPNGなど従来のフォーマットからWebPに変換する手段として標準的な方法と言えます。
非可逆圧縮時は、Jpegと同様に0〜100の品質を-q
オプションで指定するのですが、よく見ると-psnr
というオプションがありました。
-psnr <float> .......... target PSNR (in dB. typically: 42)
この-psnr
オプションを使うと、最終的な画質(PSNRによる元画像との差分量)の目標値から品質を決めてくれるようです。すごい!
Jpegも、品質と言いつつ最終的な画質は画像の性質によってまちまちです。
上のエントリーと同じ、様々なエントロピーのサンプル画像で品質とPSNRの関係をグラフにしたところ、以下のようになりました。
やはりJpegと同じように品質=データの圧縮度合いであって、どのくらい画質が劣化するかはやってみないとわからないようです。
※ このWebPのPSNR値はcwebp
コマンドの出力に含まれる数値ですが、ImageMagickなどで計算するPSNRと相関性がありません。おそらくYUVとRGBの違いかと予想していますが、WebPの特徴についてはまたじっくりまとめてみたいと思っています。
でも遅いんでしょう?
変換結果のPSNRから品質を数式で逆算することは無理っぽいので、内部的に何度か変換を試行しているものと予想されます。
あるJpeg画像(3024×4032px)を-psnr
を指定して変換すると、6.05秒かかりました。PSNRは41.98 dB
でほぼ42です(Output:
の行にあります)。
$ time cwebp tmp/sample.jpg -psnr 42 -o tmp/sample.webp
Saving file 'tmp/sample.webp'
File: tmp/sample.jpg
Dimension: 3024 x 4032
Output: 1345066 bytes Y-U-V-All-PSNR 40.55 48.55 48.61 41.98 dB
(0.88 bpp)
block count: intra4: 39077 (82.05%)
intra16: 8551 (17.95%)
skipped: 109 (0.23%)
bytes used: header: 439 (0.0%)
mode-partition: 183811 (13.7%)
Residuals bytes |segment 1|segment 2|segment 3|segment 4| total
macroblocks: | 3%| 12%| 30%| 55%| 47628
quantizer: | 25 | 24 | 19 | 15 |
filter level: | 8 | 5 | 8 | 21 |
cwebp tmp/sample.jpg -psnr 42 -o tmp/sample.webp 6.05s user 0.15s system 89% cpu 6.954 total
今度は-q
を直接指定します。いくつか値を変えて試したところ、-q 81.2
でだいだい同じ値になりました。
-q
パラメータの指定時は1.82秒で処理が完了しました。-psnr
を指定した実行では、約3倍強の時間がかかったことになります。
$ time cwebp tmp/sample.jpg -q 81.2 -o tmp/sample.webp
Saving file 'tmp/sample.webp'
File: tmp/sample.jpg
Dimension: 3024 x 4032
Output: 1346364 bytes Y-U-V-All-PSNR 40.55 48.56 48.63 41.98 dB
(0.88 bpp)
block count: intra4: 39695 (83.34%)
intra16: 7933 (16.66%)
skipped: 114 (0.24%)
bytes used: header: 439 (0.0%)
mode-partition: 186205 (13.8%)
Residuals bytes |segment 1|segment 2|segment 3|segment 4| total
macroblocks: | 3%| 12%| 30%| 55%| 47628
quantizer: | 25 | 24 | 19 | 15 |
filter level: | 8 | 5 | 8 | 21 |
cwebp tmp/sample.jpg -q 81.2 -o tmp/sample.webp 1.82s user 0.10s system 94% cpu 2.029 total
ユーザーリクエストに対しオンデマンドで変換する場合は不向きですが、バッチ処理など時間の余裕があるときは最終的な画質が安定するのでよさげです。