純生CHRONICLE2

ずっと構想段階のまま仮運用されていくwリネ2クラシック寄りブログ

画像リサイズ問題の検証

muragonブログに画像アップしたときのリサイズ処理の具合について、一度、ちゃんと検証しておく。



元の画像 (スクショ(JPEG)を切り出してPNG形式保存したもの  616,550バイト)
http://or2.mobi/index.php?mode=image&file=211300.png



原寸(924px幅)のままjpeg形式に変換してからアップした画像
UP前サイズ=212,627バイト DOWN時サイズ=42,648バイト


640px幅に縮小した後にjpeg形式に変換してからアップした画像
UP前サイズ=119,460バイト DOWN時サイズ=24,983バイト


620px幅に縮小した後にjpeg形式に変換してからアップした画像
UP前サイズ=114,780バイト DOWN時サイズ 114,780バイト


カラのブラウザを一つ開き、そこへブログ表示された画像をドラッグ&ドロップすることで、画像のURLを知ることができ、また右クリックメニューから画像サイズを調べたりすることができる。
そうすることで、muragon側で画像をどのように保持しているかを垣間見ることができるのだが、興味深い結果が出た。


原寸アップしたものは、そのサイズのまま画像を取り出せた。
しかし、だいぶ解像度を落として再保存されているようで、原寸で見てみるとひどくモスキートノイズが乗ってしまっている。
ブログでは、この画像を640px幅で表示するようなHTMLが作成されるため、目視するタイミングでは画像は縮小表示されることになるが、縮小表示されることでノイズは目立ちにくくはなる。


640px、620pxも同様に別窓ドロップしてみると、ともにリサイズ処理されているようなURLが得られる。
しかしながら、620px画像はアップ/ダウン時のサイズが同一となった。
つまり、実際には再保存処理はされておらず、アップ時そのままの画像で保管されているのだと考えられる。



最後にpng形式のまま原寸アップした結果がこちら
UP前サイズ=616,550バイト DOWN時サイズ=382,213バイト

jpegとは扱いが違い、png形式のまま640px幅にリサイズ処理がされている。
ファイルサイズ自体が一定量を超えると、大きいものは強制的に640px幅にダウンサイジングされる仕様なのかもしれない。
pngなので劣化は目立たないが、縮小してもなおファイルサイズは大きく、ダウンロード時のコストが大きい。


スマホだとどういうことになるのかはワタシでは検証できないが、おそらくは同等の結果になるものと思われる。



いまのところの結論は、
・PNG形式だと劣化は防げるがダウンロード時のコストがでかい
・JPEG形式だと、640px未満にすると劣化を防ぎつつ、ダウンロード時のコストも自前でコントロールできる。元画像が大きければ最終的にブラウザ表示されるものは細部の劣化が目立ちにくくなるのでそれはそれであり。


ということになるかな。


×

非ログインユーザーとして返信する

あと 2000文字

※は必須項目です。