概要
- 配信しているjpeg画像のファイルサイズを小さくすることによる、インフラ費用削減を検討する機会がありました。
- mozjpegのqualityを変えたり、フォーマットをWebPに変えることで、どの程度ファイルサイズを削減することができるのか調査しました。
参考記事
- JPEG画像をImageMagick/mozjpeg/Guetzliでqualityを変えつつ生成した場合のファイルサイズ、入力画像に対するPSNR、SSIM、butteraugliを比較する
- あなたのサイトのjpeg画像は過剰品質である。多分。
事前準備
環境はMacです。
# mozjpeg, webpをインストール
$ brew install mozjpeg
$ brew install webp
# 諸事情によりHomebrewにImageMagick7を入れたりパスを通したりしたくなかったので、7のBinary版を利用。
# https://imagemagick.org/script/download.php から ImageMagick-x86_64-apple-darwin17.7.0.tar.gz をDL
$ tar xvzf ImageMagick-x86_64-apple-darwin17.7.0.tar.gz
$ export DYLD_LIBRARY_PATH=~/Downloads/ImageMagick-7.0.8/lib/
$ export PATH="$HOME/Downloads/ImageMagick-7.0.8/bin/:$PATH"
$ convert --version
Version: ImageMagick 7.0.8-9 Q16 x86_64 2018-08-04 https://www.imagemagick.org
...
# Lenna画像から quality=100, YUV=420のjpg画像を作り、これをオリジナル画像とする。
$ cjpeg -quality 100 -sample 2x2 Lenna.bmp > Lenna_quality100_yuv420.jpg
調査に使用したコマンド
qualityを100から20まで変化させながら、mozjpegとwebpそれぞれで画像変換し、ファイルサイズ・SSIMを確認。
quality、ファイルサイズ、SSIMをCSVに書き出す。
for quality in `seq 100 -1 20`; do
mozjpeg_fname=mozjpeg_quality${quality}.jpg
webp_fname=webp_quality${quality}.jpg
cjpeg -quality ${quality} -sample 2x2 ${ORIGIN} > ${mozjpeg_fname}
cwebp -q ${quality} ${ORIGIN} -o ${webp_fname}
mozjpeg_ssim=$(compare -metric SSIM ${ORIGIN} ${mozjpeg_fname} diff.jpg 2>&1)
webp_ssim=$(compare -metric SSIM ${ORIGIN} ${webp_fname} diff.jpg 2>&1)
mozjpeg_fsize=$(wc -c ${mozjpeg_fname} | awk '{print $1}')
webp_fsize=$(wc -c ${webp_fname} | awk '{print $1}')
echo "${quality},${mozjpeg_fsize},${mozjpeg_ssim},${webp_fsize},${webp_ssim}" >> result.csv
done
qualityに対するファイルサイズ・SSIMの変化
- SSIMのY軸(右)は範囲が 0.8〜1 なのでご注意ください。
- 基本的にWebPの方が視覚差を低く抑えたまま、ファイルサイズを削減できている。
- jpegとWebPどちらについても、qualityと引き換えにファイルサイズを削減できる。プロジェクトの中で、画像の種別(バナー、サンプル、有料コンテンツ、etc)ごとに「画質の劣化をここまで許容できる」という基準を設けるのが重要だと思いました。
SSIMに対するファイルサイズの変化
- SSIM=0.95(mozjpegのquality=90相当) くらいの高画質では、WebPは(mozjpegの)jpegに比べ20%くらいサイズが小さい。
- SSIM=0.9(mozjpegのquality=68相当) くらいの中画質(?)では、30〜40%くらいサイズが小さい。
- 画質の基準が保守的な場合(劣化は認められない、全てquality=90以上など)、WebPを使うメリットは小さい。
逆に攻められる場合(quality=60相当まで下げてOKなど)、WebPを使うメリットが大きくなる。
まとめ
- 画像配信のためのインフラ費用を削減したい場合、まず「どのような画像を配信していて、それぞれどこまで画質を下げられるか」を決めることが大切。
- オリジナル画像を保持しつつ変換した画像を配信する設計にしておけば、「下げすぎた」と思った時すぐもとに戻せる。そのため保守的になる必要はなく、攻めのサイズ削減ができる。
- 画質を中画質(mozjpegのquality60〜70相当?)まで下げられる場合、WebPにすることでサイズを30〜40%削減することができる。
- ただブラウザの種類やバージョンによってはWebPをサポートしてないので、jpegとWebP両方変換しておいて、呼び出し元に応じて切り替えるのが良さそう。
おまけ
qualityやSSIMの数値だけ見ても、実際どのくらいの画質かイメージしづらいので、変換後の画像を適当に添付します。
| SSIM | quality | 画像 |
|---|---|---|
| 0.989212 | 100 |  |
| 0.96 | 94 |  |
| 0.94 | 87 |  |
| 0.92 | 77 |  |
| 0.90 | 67 |  |
| 0.88 | 53 |  |
| 0.86 | 40 |  |