最近話題のGoogle製JPEGエンコーダGuetzliの検証を行ってみました。かなりの所要時間を要するので、ある程度まとまった単位で分割して記載します。
テスト条件
- 処理環境
- OS
- Windows 10 Home (64bit)
- CPU
- Core i5 3337U (1.8GHz / Max. 2.7GHz)
- Memory
- 4GB
- Imagemagick(libjpeg検証用)
- 7.0.1-2 Q16 x64
- Guetzli
- guetzli_windows_x86-64.exe V1.0
- 入力画像
空。雲と空の曖昧なグラデーション部が多く、明確な輪郭は少ない。
- 入力画像解像度
- 1920x1440 pixel
- ビット深度
- 24 bit
テスト条件補足
- 非圧縮TIF画像を入力画像として用意したが、GuetzliはTIFに対応していないため、予めPNGに変換した。
- 解像度4200x3154ではメモリが枯渇してOSによる警告および、アプリケーション自体の異常終了が発生したため、予め長辺がFullHD相当の1920pxにリサイズした画像を入力画像とした。
- Windowsによる警告
- Guetzliのエラーメッセージ
- Windowsによる警告
Unhandled expection. Most likely insufficient memory available. Make sure that there is 300MB/MPix of memory available.
Guetzli should be called with quality >= 84, otherwise the output will have noticeable artifacts. If you want to proceed anyway, please edit the source code. Guetzli processing failed
結果
Condition_Quality | OutputSize [Bytes] | ProcessingTime [sec] |
---|---|---|
libjpeg_10 | 24,291 | 0.16 |
libjpeg_20 | 35,330 | 0.27 |
libjpeg_30 | 47,259 | 0.15 |
libjpeg_40 | 58,428 | 0.16 |
libjpeg_50 | 69,655 | 0.16 |
libjpeg_60 | 82,340 | 0.15 |
libjpeg_70 | 103,393 | 0.30 |
libjpeg_80 | 142,613 | 0.22 |
libjpeg_84 | 173,414 | 0.23 |
libjpeg_85 | 180,249 | 0.17 |
libjpeg_86 | 194,282 | 0.35 |
libjpeg_87 | 202,433 | 0.17 |
libjpeg_88 | 220,210 | 0.19 |
libjpeg_89 | 229,921 | 0.23 |
libjpeg_90 | 323,260 | 0.19 |
libjpeg_91 | 349,969 | 0.33 |
libjpeg_92 | 368,705 | 0.28 |
libjpeg_93 | 419,353 | 0.26 |
libjpeg_94 | 480,215 | 0.24 |
libjpeg_95 | 548,990 | 0.26 |
libjpeg_96 | 657,608 | 0.32 |
libjpeg_97 | 777,019 | 0.37 |
libjpeg_98 | 934,588 | 0.24 |
libjpeg_99 | 1,334,466 | 0.43 |
libjpeg_100 | 1,868,807 | 0.38 |
guetzli_84 | 131,937 | 117.74 |
guetzli_85 | 146,034 | 131.31 |
guetzli_86 | 155,491 | 138.84 |
guetzli_87 | 160,886 | 147.11 |
guetzli_88 | 172,701 | 192.43 |
guetzli_89 | 183,676 | 195.40 |
guetzli_90 | 198,000 | 182.16 |
guetzli_91 | 216,982 | 189.56 |
guetzli_92 | 261,865 | 198.59 |
guetzli_93 | 329,867 | 239.18 |
guetzli_94 | 411,397 | 294.32 |
guetzli_95 | 498,206 | 376.53 |
guetzli_96 | 662,492 | 525.71 |
guetzli_97 | 904,085 | 622.04 |
guetzli_98 | 1,261,812 | 1,303.04 |
guetzli_99 | 1,898,535 | 1,035.54 |
guetzli_100 | 1,943,397 | 291.80 |
考察
- Guetzliは実用的とは言い難い劣悪な動作パフォーマンスを示す
- 安定してlibjpeg(Imagemagick)より100倍以上遅く、パラメータによっては1000倍以上遅い
- libjpegはqualityパラメータによる処理時間差異はほとんど無いが、GuetzliはQualityパラメータが上昇するにつれて概ね遅くなる傾向がある(98から低下する?)
- Core i5 3337Uは2core/4threadであるが、guetzli_windows_x86-64.exeはCPU使用率25%で張り付くことから、シングルスレッド動作となっており、マルチコアCPUによる処理速度向上は見込めない
- Turbo Boostは効いているため、ベースクロックおよびブースト時の動作クロックが高いプロセッサ搭載機で所要時間短縮を図ることはできそう
- 処理対象画像が複数あるならシングルスレッド動作であることを逆手にとって、並列実行することでスループット向上を図れそう(但しメモリを潤沢に搭載する必要がある)
- libjpegと比較して同一クオリティなら画像サイズが小さいという触れ込みだが、このサンプル画像では有意に小さいとは言えない
- 但し、「同一クオリティ」とは何なのかの定義にもよる。単純にQualityパラメータの設定値そのものではなく、人間の目による視覚的な評価では違う結果になる可能性もある
- オリジナル画像から失われる情報はlibjpegもGuetzliも似たような領域で発生する
- Guetzli (Quality 100)と元画像との差分の正規化イメージ
- libjpeg (Quality 100)と元画像との差分の正規化イメージ
- Guetzli (Quality 100)と元画像との差分の正規化イメージ
- 以上より、本サンプル画像のように明確なエッジの少ない画像に対してGuetzliを積極的に利用する理由は無いと考えられる
- 異なる画像パターン及び高解像度画像の場合については別途要検証
以上。
*1:noticeable artifactsが現れるほど汚いため、実用範囲外として除外していると思われる