引き続きJPEGエンコーダGuetzliの検証を行います。前回はエッジのはっきりしない空画像だけでの試行でしたので、今回は入力画像のデータパターンを増やしてみました。
wave.hatenablog.com
測定条件
- 基本的に前回同様
- libjpeg(Imagemagick)でのJPEGエンコードはQualityパラメータの値に依らず1秒未満のため測定対象外とする
- Qualityパラメータはguetzliで指定可能な下限値84と上限値100の2パターンのみとする
Data Pattern: Plum
特徴
解像度1920x1442、各色8bit、sRGB
梅の花の雄しべにピントを合わせています。その付近はエッジの明確なシャープな領域ですが、離れるにつれてボケ具合は大きくなり画面上の多くの領域は被写界深度外のためなだらかなグラデーションとなっています。
結果
| Quality | OutputSize [Bytes] | CompressionRatio | ProcessingTime [sec] |
|---|---|---|---|
| guetzli_84 | 198,556 | 6.04% | 164.9 |
| guetzli_100 | 2,234,401 | 67.92% | 369.3 |
| libjpeg_84 | 242,570 | 7.37% | - |
| libjpeg_100 | 2,169,127 | 65.94% | - |
比較
比較のためピクセル等倍でクロップした画像は以下の通り。
- libjpeg/guetzliそれぞれのQuality 100
↑画像としてどちらも違和感は無い。guetzliは6分以上エンコード時間がかかったうえ、libjpegより圧縮率が悪いため、採用する理由なし。
- Quality 84のlibjpegと元画像の差分の正規化画像
↑エッジの精細感が僅かに失われているが違和感はない。
- Quality 84のguetzliと元画像の差分の正規化画像
↑こちらもエッジの精細感が僅かに失われているが、背景に格子状のパターン(guetzli特有のブロックノイズ？)が出現している。
Quality84同士で比較すると、guetzliの方が高圧縮率を達成しているが、視認できるレベルで格子状のパターンが表れるため画質はlibjpegの方が優れる。
Data Pattern: ST
特徴
解像度1440x1920、各色8bit、sRGB
空以外は建造物の細かいパターンが多く、高解像度が要求されるシーン。
結果
| Quality | OutputSize [Bytes] | CompressionRatio | ProcessingTime [sec] |
|---|---|---|---|
| guetzli_84 | 304,439 | 9.75% | 213.7 |
| guetzli_100 | 2,204,228 | 70.57% | 613.16 |
| libjpeg_84 | 292,127 | 9.35% | - |
| libjpeg_100 | 2,134,204 | 68.33% | - |
比較
比較のためピクセル等倍でクロップした画像は以下の通り。
- libjpeg/guetzliそれぞれのQuality 100
↑画像としてどちらも違和感は無い。guetzliは10分以上エンコード時間がかかったうえ、libjpegより圧縮率が悪いため、採用する理由なし。
- Quality 84のlibjpegと元画像の差分の正規化画像
↑主に高輝度領域(低輝度領域と高輝度領域のエッジ付近)で差分が目立つものの、画像に不自然さは感じられない。
- Quality 84のguetzliと元画像の差分の正規化画像
↑差分画像から判断するとlibjpegより差分が少なさそうであるが、目視の限りではどちらが綺麗・汚いということはなく似たような品質に思える。
Plumとは逆に、guetzliの方が圧縮率が低く、3分半程度のエンコード時間がかかることを考慮するとguetzliを利用すべき理由は見当たらない。
Data Pattern: TT
特徴
解像度1920x1280、各色8bit、sRGB
STと類似のパターン。
結果
| Quality | OutputSize [Bytes] | CompressionRatio | ProcessingTime [sec] |
|---|---|---|---|
| guetzli_84 | 287,076 | 9.35% | 196.78 |
| guetzli_100 | 2,321,258 | 75.61% | 612.21 |
| libjpeg_84 | 301,463 | 9.82% | - |
| libjpeg_100 | 2,288,867 | 74.56% | - |
比較
比較のためピクセル等倍でクロップした画像は以下の通り。
- libjpeg/guetzliそれぞれのQuality 100
↑画像としてどちらも違和感は無い。guetzliの方が2017の窓文字付近が僅かにシャープかもしれないが、10分以上エンコード時間がかかるうえ、libjpegより圧縮率が悪いため、積極的に採用する理由なし。
- Quality 84のlibjpegと元画像の差分の正規化画像
↑主にエッジ付近で差分が目立つものの、画像に不自然さは感じられない。
- Quality 84のguetzliと元画像の差分の正規化画像
↑差分画像から判断するとlibjpegより差分が少なさそうであるが、目視の限りではどちらが綺麗・汚いということはなく似たような品質に思える。
データパターンとして似ていそうなSTと異なり、Plum同様にguetzliの方が僅かに圧縮率が高い。それでも3分以上のエンコード時間がかかることを考慮するとguetzliを積極的に利用する理由は見当たらない。
中間まとめ
これまでの検証ではguetzliを積極的に利用すべきパターンが見当たりません。システムリソースが潤沢なマシンで高解像度画像を、シングルボードコンピュータで低解像度画像の検証を別途実行中ですが、一晩で終わらないレベルの遅さなので実用性はかなり低いと言わざるを得ないでしょう。
少なくともフォトグラファー向きではないと判断して問題ないと思います。高画質が必要なら素直に非圧縮フォーマットを使えばいいですし。どうしてもJPEGである必要があれば品質100で書き出せばいいでしょうし。
また、写真ではなく比較的小さな図やグラフ、スクリーンショットなどはどうかと試してみたりもしています。が、libjpegより高圧縮率を達成しても、入力画像のPNG(可逆圧縮が可能)の方が小さいという有様で、guetzliが適しているパターンが私の検証ではこれまでに全く見つかっていません。Webデベロッパーやブロガー的な用途にもマッチし無さそうです。
以上。
