今年の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にも未対応。進んで使うものではないと思う。