画質とサイズの検証(2012-07-04) 
動機
「画質を保持しながら画像ファイルを最大1/5に縮小」というのは本当ですか？
と疑問が沸いたので実際に検証を行ってみた。
と疑問が沸いたので実際に検証を行ってみた。
比較サンプル
上記の製品ページからは適当なサンプルが見つけられなかったので、
以下の報道で挙げられていたサンプル画像 01.jpg, 02.jpg を拾って来た。
Ubuntu 10.04 LTS 上の以下のソフトで圧縮を行った。
GIMP では 01.jpg を読み込み「名前をつけて保存」することで圧縮した。
その際、パラメータは、最適化「ON」、サンプリング「1x1,1x1,1x1(最高品位)」に固定し、品質のみを変更。
ファイル名は例えば品質「75」なら 01_gi075.jpg とした。
ImageMagick では以下のようにして圧縮を行った。
GIMP と ImageMagick を比較すると、ImageMagick の方がファイルサイズが 426 バイト多くなっていた。
バックエンドのライブラリが同じなので当然と言えば当然なのだが、以下ようにして比較した結果、相違点はヘッダ部分のみで、画像データ部分は同一であることが分かった。
以下の報道で挙げられていたサンプル画像 01.jpg, 02.jpg を拾って来た。
- INTERNET Watch / 2012-06-29: Linuxサーバー向けのJPEG画像圧縮ソフト〜画質を落とさず容量を最大1/5に
Ubuntu 10.04 LTS 上の以下のソフトで圧縮を行った。
- GIMP 2.6.8
- ImageMagick 6.5.7-8 2012-04-30 Q16
GIMP では 01.jpg を読み込み「名前をつけて保存」することで圧縮した。
その際、パラメータは、最適化「ON」、サンプリング「1x1,1x1,1x1(最高品位)」に固定し、品質のみを変更。
ファイル名は例えば品質「75」なら 01_gi075.jpg とした。
ImageMagick では以下のようにして圧縮を行った。
convert -quality 75 01.jpg 01_im075.jpg
GIMP と ImageMagick を比較すると、ImageMagick の方がファイルサイズが 426 バイト多くなっていた。
バックエンドのライブラリが同じなので当然と言えば当然なのだが、以下ようにして比較した結果、相違点はヘッダ部分のみで、画像データ部分は同一であることが分かった。
xxd -c 1 01_gi075.jpg | awk '{print $2,$3}' > 01_gi075.txt
xxd -c 1 01_im075.jpg | awk '{print $2,$3}' > 01_im075.txt
diff 01_gi075.txt 01_im075.txt | lv
このため、ファイルサイズの小さい GIMP による圧縮のみを比較した。 比較方法
比較は GNU Octave を用いて以下のコードで行った。
function imdiff(fn0, fn1)
I0 = double(imread(fn0));
I1 = double(imread(fn1));
printf("sam: %f, sas: %f, ss: %f\n", mean(abs(I0 - I1)(:)), std(abs(I0 - I1)(:)), std((I0 - I1)(:)));
end
それぞれの意味としては以下のようになる。- sam : 差の絶対値の平均
- sas : 差の絶対値の標準偏差
- ss : 差の標準偏差
比較結果
fn0 に元画像 "01.jpg" を、fn1 に圧縮画像を与えて imdiff() により比較した結果は以下のようになった。
まず、「画質の保持」について、少なくとも上記のサンプルについては次の2点の事が確認できた。
| fn1 | sam | sas | ss | file size |
|---|---|---|---|---|
| 01.jpg | 0 | 0 | 0 | 14727062 |
| 02.jpg | 5.033550 | 4.486154 | 6.742545 | 2723647 |
| 01_gi100.jpg | 0.093266 | 0.342065 | 0.354552 | 13393124 |
| 01_gi075.jpg | 5.175311 | 4.609310 | 6.930230 | 2655072 |
| 01_gi076.jpg | 5.095335 | 4.536210 | 6.821986 | 2727769 |
| 01_gi077.jpg | 5.002807 | 4.456097 | 6.699600 | 2820493 |
まず、「画質の保持」について、少なくとも上記のサンプルについては次の2点の事が確認できた。
- 非可逆圧縮である JPEG を使ってる以上、画質が低下することは常識であるし、当製品についても例外ではなかった。
- Ubuntu 10.04 LTS において標準的な OSS で圧縮した場合と比較して圧縮時の品質パラメータにして 1 ポイント、ファイルサイズにして 3.4% 程度のメリットが確認できた。
結論
結論としては以下の3点だろうか？
以上を踏まえて製品の紹介を読んでみると、この製品の落とし所は、Web 上で画像を表示した際、画質の低下が気にならない程度の圧縮率をファイル毎に自動的に設定し再圧縮を行うことで、サーバー容量を節約するとともに、再圧縮時のパラメータ設定の手間を省くところにあるらしい。
注意すべき点は 1/5 と言うのがほぼ非圧縮の元画像から 1/5 が最大であり、既に(1/5程度に)圧縮済みの画像から更に 1/5 ではない点。
要するに Web 用としては過剰品質になっている画像を、Web 用として適正な圧縮率に自動的に再圧縮してくれるソフトということのようである。
「画質を保持しながら画像ファイルを最大1/5に縮小」と書かれるとついつい過剰な期待をしてしまうが、標準的な非可逆圧縮のフォーマットに乗っかっている以上、非常識なレベルの画質向上を期待するのは、むしろそっちの方が非常識である。そもそも、非常識なレベルで画質が向上するとは誰も言っていないんだけど、タイトルの付け方はミスリーディングを狙っているんじゃないかと思ってしまう。
- JPEG と明記してあるので、常識があれば画質が低下することは自明である。
- 数値データとして示されていない以上は「画質の保持」は主観の問題である。
- JPEG の圧縮率としては常識的なレベルで十分な「画質の保持」が成されていた。
以上を踏まえて製品の紹介を読んでみると、この製品の落とし所は、Web 上で画像を表示した際、画質の低下が気にならない程度の圧縮率をファイル毎に自動的に設定し再圧縮を行うことで、サーバー容量を節約するとともに、再圧縮時のパラメータ設定の手間を省くところにあるらしい。
注意すべき点は 1/5 と言うのがほぼ非圧縮の元画像から 1/5 が最大であり、既に(1/5程度に)圧縮済みの画像から更に 1/5 ではない点。
要するに Web 用としては過剰品質になっている画像を、Web 用として適正な圧縮率に自動的に再圧縮してくれるソフトということのようである。
「画質を保持しながら画像ファイルを最大1/5に縮小」と書かれるとついつい過剰な期待をしてしまうが、標準的な非可逆圧縮のフォーマットに乗っかっている以上、非常識なレベルの画質向上を期待するのは、むしろそっちの方が非常識である。そもそも、非常識なレベルで画質が向上するとは誰も言っていないんだけど、タイトルの付け方はミスリーディングを狙っているんじゃないかと思ってしまう。
タグ
コメントをかく