●実験に用いたサンプル画像


●コマンドラインオプション
　用いた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にも未対応。進んで使うものではないと思う。