2007年6月25日月曜日

画像データ検証④完

画像UPテストの最後です。本来「禁じ手」なのですが、元データを拡大現像して、2回トライしました。ディスク上の重さはそれぞれ12.9MB、9.64MBという重量級ファイルだったため、さすがにサーバにハネられました。

「Unable to Upload」(アップロードできません)
「Please try again in a few minutes」(2~3分以内に再度お試し下さい)
というエラーメッセージが出ました。
これは「8MB」という制限を承知で破っているので、文句はありません。

では最後に、これも「禁じ手」なのですが、元データを151%に拡大現像してUPしてみました。ディスク上のサイズは5500×4125pxl、8.46MBです。UPには成功しました。表示されたサムネイルは32.829KB、フルスクリーンで224.557KBです。

やはり想像していた通り、重くなると思いきや、サムネイルも少し軽くなっていますし、フルスクリーンに関しては極端にダウンサイジングした一つ前の画像を別として、最も軽くなっています。

肝心の画像は無理な引き伸ばしのせいで、フルスクリーンで点検すると、元々甘いピントが目立つ領域に入ってきています。

今回の検証をまとめると次のようになります。
①元データがサーバ制限の近辺であれば、アスペクト4:3の35mm判はサムネイルでは408×308pxl、フルスクーリンで1600×1200pxlに自動縮小されてしまう。
②サイズを少々大小しても、顕著な色転びやトーンジャンプもなく正常に表示される。
③規定サイズでUPすれば、重さ制限に引っかかることはありえないので、今後は長辺1600pxlでJpeg現像しても差し支えはない。

欲張った画像をUPしても結果は変わらんよ」とGoogleに諫められた感のある実験でした。

あとは何とか表示上の重さをどこまでめいっぱい稼げるか、が課題です。重さは、表現できる色階調や解像度と密接なつながりがあるはずです。
RAW・TIFFレタッチ時に見えていた細かい色や細部がJpegに現像したとたん、消えてしまうのが現実です。いかに重いファイルをサーバに潜り込ませることが出来るか。目安としては35mm判のJpegで10MBほどで十分と思います。ただ、それにはレンタルサーバでは恐らく足りず、テラ級の自宅サーバを構えざるを得ないのでしょうか?

Jpeg画像をUPする際に使われる「ハイパーテキスト転送プロトコル(http)」という通信処理の仕組みも勉強し直さなければなりません。

その辺りがおぼろげに見えてきましたので、いま本格的なHPを外部発注でデザインしてみようと、考えています。

追記:今回のテストで使ったのはRICOH Caplio GX100というコンパクトデジタルカメラです。1001万画素といいますが、DMRの作例では一概には言えませんが、おおむね、この4回の検証でお見せしたものより、サイズは同じながら、重いデータがアップできています。数字的なことは、ご自身でサムネイルとクリックしたフルスクリーンの画像を右クリックして「プロパティ」をご確認いただければ、一目瞭然です。

これは16bit Color Depthの階調分の重さではないか?と当たりをつけてはいるのですが、、、