今年の3月にJPEGエンコーダguetzliのver1.0が発表された。
Googleの名前があることでかなり注目されている。
そのguetzliがどのような画像処理をしているのか調べるため、何度もエンコードするとどうなるかのか実験をやってみた。
●実験の狙いと目的
広く一般的に使われているJPEGエンコードのライブラリlibjpegにはスムージングのオプションが存在する。これはスムージング(ぼかしのようなもの)をしてからJPEGに変換するというもので、スムージングによって画質は変化するものの、結果的には見た目の画質劣化を抑えつつファイルサイズが縮むというものだ。
guetzliでもこれに類する処理を自動でやっているのではないかと推測。
そこでguetzliでエンコードした画像を再びエンコードするということを何度も繰り返すことにより画質の変化が蓄積していき、結果的に画質の変化を可視化できないか? というのが実験の狙い。
●実験に用いたサンプル画像

●コマンドラインオプション
用いたguetzliのバージョンはv1.0.1。ここで公開されているバイナリを使用。(Windows用とLinux用を試したがどちらも同じ結果を出力する模様)
コマンドでは特にオプションは付けず次のように実行した。デフォルトでは--quality 95と同じ結果になる。
guetzli input.jpg output.jpg
●エンコード結果
01回目
02回目
03回目
04回目
05回目
06回目
07回目
08回目
09回目
10回目
11回目
12回目
13回目
14回目
15回目
16回目
17回目
18回目
19回目
20回目
21回目
22回目
21回目と22回目のファイルは完全に同一。これ以降は同じ結果が続くためここで終了。
●最終結果の画像

●考察
輪郭部分が強調されているのが分かる。2、3回目の時点ですでに輪郭が強調されているのを目視できる。さらに回数が進むとブロックノイズを輪郭と判断したのかそこも強調されている。
輪郭を強調してもファイルサイズが縮んでいるのをみるに、おそらく人の目では分かりにくい部分をノイズとして除去しているのだろう。「シャープにしておけば高画質と思われる」という企みだろうか。
2、3回のエンコードで画質の変化を目視できてしまうというのは注意が必要かもしれない。guetzliでエンコードされた画像を加工をし、それを再びguetzliでエンコードするだけで元の画像とは違う画質になってしまう。
●ちなみに
guetzliでエンコードした画像をmozlibで最適化するとなんと画質の変化なしにさらにファイルサイズが縮む。
これはどういうわけかと調べてみたら、guetzliではベースラインJPEG(シーケンシャルJPEG)のみの対応で、プログレッシブJPEGに未対応のためだと分かった。(guetzliがプログレッシブJPEGに未対応なのはモバイル機器でのデコード負荷が増えるためと説明されているらしい)
一般にプログレッシブJPEGの方がファイルサイズが縮む傾向があり、mozlibではその部分にさらなる工夫を加えてファイルサイズを縮めている。
guetzliはエンコードに時間がかかるし、輪郭も強調されてしまうし、プログレッシブJPEGにも未対応。進んで使うものではないと思う。
Googleの名前があることでかなり注目されている。
そのguetzliがどのような画像処理をしているのか調べるため、何度もエンコードするとどうなるかのか実験をやってみた。
●実験の狙いと目的
広く一般的に使われているJPEGエンコードのライブラリlibjpegにはスムージングのオプションが存在する。これはスムージング(ぼかしのようなもの)をしてからJPEGに変換するというもので、スムージングによって画質は変化するものの、結果的には見た目の画質劣化を抑えつつファイルサイズが縮むというものだ。
guetzliでもこれに類する処理を自動でやっているのではないかと推測。
そこでguetzliでエンコードした画像を再びエンコードするということを何度も繰り返すことにより画質の変化が蓄積していき、結果的に画質の変化を可視化できないか? というのが実験の狙い。
●実験に用いたサンプル画像

●コマンドラインオプション
用いたguetzliのバージョンはv1.0.1。ここで公開されているバイナリを使用。(Windows用とLinux用を試したがどちらも同じ結果を出力する模様)
コマンドでは特にオプションは付けず次のように実行した。デフォルトでは--quality 95と同じ結果になる。
guetzli input.jpg output.jpg
●エンコード結果
01回目
02回目
03回目
04回目
05回目
06回目
07回目
08回目
09回目
10回目
11回目
12回目
13回目
14回目
15回目
16回目
17回目
18回目
19回目
20回目
21回目
22回目
21回目と22回目のファイルは完全に同一。これ以降は同じ結果が続くためここで終了。
●最終結果の画像

●考察
輪郭部分が強調されているのが分かる。2、3回目の時点ですでに輪郭が強調されているのを目視できる。さらに回数が進むとブロックノイズを輪郭と判断したのかそこも強調されている。
輪郭を強調してもファイルサイズが縮んでいるのをみるに、おそらく人の目では分かりにくい部分をノイズとして除去しているのだろう。「シャープにしておけば高画質と思われる」という企みだろうか。
2、3回のエンコードで画質の変化を目視できてしまうというのは注意が必要かもしれない。guetzliでエンコードされた画像を加工をし、それを再びguetzliでエンコードするだけで元の画像とは違う画質になってしまう。
●ちなみに
guetzliでエンコードした画像をmozlibで最適化するとなんと画質の変化なしにさらにファイルサイズが縮む。
これはどういうわけかと調べてみたら、guetzliではベースラインJPEG(シーケンシャルJPEG)のみの対応で、プログレッシブJPEGに未対応のためだと分かった。(guetzliがプログレッシブJPEGに未対応なのはモバイル機器でのデコード負荷が増えるためと説明されているらしい)
一般にプログレッシブJPEGの方がファイルサイズが縮む傾向があり、mozlibではその部分にさらなる工夫を加えてファイルサイズを縮めている。
guetzliはエンコードに時間がかかるし、輪郭も強調されてしまうし、プログレッシブJPEGにも未対応。進んで使うものではないと思う。
コメント