Help us understand the problem. What is going on with this article?

Jpegエンコーダのファイルサイズ対決 Photoshop vs ImageMagick vs MozJPEG vs Guetzli & WebP

More than 1 year has passed since last update.

エンコーダの性能として、ファイルサイズ効率を品質1刻みで比較してみました。Web用途を前提とした「同じ画質なら軽い方が勝ち」という基準の対決です。

WebPについても知りたかったので参戦してます。

Web用途ではデコード時間なども大事ですが、この記事ではファイルサイズが軽いかどうかに着目します。

また、品質はJpeg出力時のパラメータ(0-100)、画質は元画像との定量的な差分(SSIM)としています。

知りたかったことや仮説

  • PhotoshopのJpegエンコーダは賢い気がするが実際どうか。
  • 後発のMozJPEGやGuetzliはImageMagickよりどのくらい優れているのか。
  • WebPはそれらJpegエンコーダに比べてどのくらい優位性があるのか。

まとめ

  • WebPは軽い。
  • PhotoshopのJpegエンコーダはやはり賢い。
  • Photoshopの品質は尺度が独特。Web用には50前後で十分かもしれない。
  • Guetzliは処理が遅いがImageMagickやMozJPEGと一線を画す結果が出る。
  • MozJPEGとImageMagickに大きな差がない(Jpegライブラリが同じだから?)

元画像

写真はぱくたそさんから拝借して、480x480にトリミングしたPNG24画像です。

写真

変換処理

品質$Qを0から100まで1刻みで変化させて、元ファイル$SRCから変換先$DEST変換を行います。品質以外のパラメータは基本的にデフォルトのままとしました(そのように使われるケースが多いであろうから)。

  • Photoshop
    • CC 2018 (19.0)
    • Web用に保存(従来)機能を利用(最適化あり)
    • こちらの記事を参考にJSXを作成
  • ImageMagick
    • 7.0.8-14 (Homebrew)
    • convert -quality $Q $SRC $DEST
  • MozJPEG
    • 3.3.1 (Homebrew)
    • 直接のPNG入力に対応していないのでTGAをロスレス経由 convert $SRC $SRC.tga
    • cjpeg -quality $Q -targa $SRC.tga $DEST
  • Guetzli
    • 1.0.1 (Homebrew)
    • $Q=84〜100のみ
    • guetzli --quality $Q $SRC $DEST
  • WebP
    • 1.0.0 (Homebrew)
    • cwebp -quiet -q $Q -o $DEST $SRC

サブサンプリングやインターレースについてはこちらの記事を参照ください。

結果

  • 横軸: 画質(元画像とのSSIM)
    • Jpeg/WebPから一度PNG24に変換してからYUVカラーモデルとして計算
    • compare -metric SSIM -colorspace yuv $SRC $PNG24 NULL:
  • 縦軸: 出力ファイルサイズ

Jpeg_Webpエンコーダ比較_-_Google_スプレッドシート.png

点の配置が右下にあるほど、高い画質に対してもファイルサイズが小さく、効率がよいということになります。

  1. WebP(オレンジ)
  2. Photoshop(緑)とGuetzli(青)
  3. ImageMagick(赤)とMozJPEG(黄)

というような並びに見えます。

SSIM 0.95のファイルサイズで対決

SSIMは0.95以上はオリジナルと見分けが付きにくいと言われています。

そこでSSIMが0.95±0.005、つまり0.945〜9.955の範囲に収まったサンプルの平均ファイルサイズを出してみます。

つまり、見分けが付きにくい範囲でどこまでファイルを軽く出るのかというチキンレース的な勝負です。

WebP圧勝

結果はWebPのファイルサイズがダントツで軽く、次いでPhotoshop、Guetzliという順位になりました。

定評のあるMozJPEGが最も振るわずという意外な結果です。

WebPはフォーマット自体が違うのですが、同じSSIM値に対しMozJPEGの半分以下に抑えられたのは驚きです。普及に期待したいです。

1.WebP 2.Photoshop 3.Guetzli 4.ImageMagick 5.MozJPEG
Filesize KB 27.45 40.49 43.09 53.09 55.74
vs MozJPEG % 49.25 72.63 77.30 95.25 100.00
Q avg. 76.5 47.5 85 87.5 88
  • Filesize KB: 平均ファイルサイズ(KB)です。
  • vs MozJPEG %: 最もファイルサイズが大きかったMozJpegを100としたときの割合です。
  • Q avg.: 平均品質値です。

当然ながら、画像の質や解像度などによって順位は変動する可能性があります。一例として参考ください。

MozJPEGの-optimizeオプション

MozJPEGには、DCTテーブルを最適化する-optimizeというオプションがあります。結果が振るわなかったので念のため-optimizeを追加した結果も出してみましたが、2%ほどの改善に留まりました。

Photoshopの品質値は独特

Photoshopだけ、47.5という普段は滅多に使わないであろう値でSSIM 0.95となっています。

Photoshopは品質について独特の尺度を持っているようで、ImageMagickなどの感覚で80や90を指定すると過剰品質になりそうです。

品質とSSIM・品質とファイルサイズ

個別に見てみます。

Jpeg_Webpエンコーダ比較_-_Google_スプレッドシート.png

Jpeg_Webpエンコーダ比較_-_Google_スプレッドシート.png

画質重視のPhotoshop

Photoshop(緑)は他に比べて品質と画質の関係が直線的で独特です。総じて高い画質がでています。なんとなく、品質と画質が感覚的に一致するように内部で補正されているかのように見えます。

画質が50付近で急激に上昇していますが、これはPhotoshopには品質51を境にサブサンプリングが4:2:0から4:4:4に変わる性質があるからです。

それもあってファイルサイズが総じて大きくなっています。エクスポート機能(Web用に保存)を用いているので、無駄なメタデータは除去されているはずですが、それでも大きい。

ImageMagickとMozJPEG

品質とSSIMのグラフではImageMagick(赤)の曲線がほとんど見えませんが、これはMozJPEG(黄)と重なっているからで、結果が酷似しています。

また、ImageMagick(赤)は90あたりで急に上昇しています。これもImageMagickは90からサブサンプリングが4:2:0から自動的に4:4:4になるためです。

これ以外にも違いがありそうなものですが、理由は不明です。convert -list formatでライブラリを確認しても普通にlibjpeg 90と出ます。

Guetzli

Guetzli(青)は84未満の品質を指定できないため、グラフのように短い曲線になります。ImageMagickやMozJPEGより画質が高く、ファイルサイズが抑えられています。

Guetzliは独自のButteraugliという画質指標に基づいているのでフェアではないかなと思いましたが、SSIM基準でも高い効率が確認されました。

それにしても処理時間が長い… 実験時間の大部分はguetzliコマンドの実行に費やされました。

WebP

WebPは画質に上限があり、品質100付近ではJpegに追い抜かれる格好になっています。

フォーマットの制約によるものなのかわかりませんが、あくまでWeb公開用の画像フォーマットで、過剰な高画質は不要と割り切っているようにも見えます。

以上です。知りたかったことがいろいろ確かめられてスッキリ!

Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
Comments
No comments
Sign up for free and join this conversation.
If you already have a Qiita account
Why do not you register as a user and use Qiita more conveniently?
You need to log in to use this function. Qiita can be used more conveniently after logging in.
You seem to be reading articles frequently this month. Qiita can be used more conveniently after logging in.
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
ユーザーは見つかりませんでした