あおもりくまブログアクセスカウンター

2009年1月6日火曜日

PDFに使う画像:Bitmapって実はJPEGやPNGより軽い

コンテンツに画像を埋め込む時、写真だとJPEG。キャプチャーならPNGやGIFと使い分けるのが定番の手法である。
そのほうがコンテンツの全体の容量が減って表示も軽くなるし、容量を抑えられる。

ただ、Office関連ソフトについては全く逆。
Microsoft Office / OpenOffice.org に限らず、これらのOffice Suite に埋め込む画像は、ファイルを保存する際に画像を可能な限り圧縮して保存する。

数MBのBitmap形式画像を埋め込んでも、文書ファイルの保存時の容量が数百KBになるのはそのためだ。
しかも画像が最初から圧縮されていないBitmapだからこそ余計な処理が掛からず、それらをPDFにエクスポートした時も、Bitmap画像は自動的に指定されたLZHかZip形式でPDF内部に格納される。
場合によっては文書ファイルよりもPDFの方が小さくなる事もある。これはそのソフトウェアがどのようなファイル圧縮を行なっているかによるのだが、勿論、MSとOOoで比較して同じ文書だとしても容量は異なるし、PDFに出力するソフトウェアによっても容量は変わる。
通常のPDF文書は300dpiや600dpiくらいで充分だが、実際の所、あまり極端に容量に差が出ない。
だから配布する時の容量が気になる人は、そのPDF文書の目的によってかなり高解像度な指定にしても良いし、そんなに解像度を必要としないものなら300でも600でもいいのだ。

もちろん、Bitmapともなると無圧縮の画像だけに、画像のサイズ=容量となってしまう。だから圧縮するのにも限界があるわけで、Bitmapの色情報を減色することで圧縮した時に2倍程の差が出る。

通常は24ビットのフルカラーや、16ビットで保存されるBitmapだけど、8ビットに綺麗に減色してくれるソフトウェアもある。しかも2手間(重複色の統合/未使用色の削除)まで行なうとパレットの最適化によって更に圧縮した時の容量が減る。
それでもBitmapには違いないので、より軽くなったBitmapはこれらのOfficeソフト上に貼り付けて使用した時にスクロールも滑らかだし、パラパラと時間を要して表示される事無く、サササッと表示される。

Mozilla Composerのマニュアルを作っていた昔にもこの件に関して記載したことがあるが、まだまだコツを掴んでいない人がいるのでたまには記事としてネットに情報をバラ撒くほうが良いだろう。

ちなみに24ビットと8ビットのBitmapのサイズの違いは・・・

35個で 24bit=8.59MB / 8bit=2.91MB とサイズが3分の1まで減り、それらをZip圧縮すると



24bit = 274MB / 8bit = 166KB となる。4割も差が出る。

元々は 8.59MBの容量のものが256色に最適化されてPDF内に格納されると166KBにまで圧縮格納される。
つまり、 (8.59*1024)÷166=だいたい50分の1 程度にまで減ることになる。
これがJPEGやPNGにしてしまうと圧縮形式の画像を圧縮する事自体に効果が無いのでBitmapよりも容量が大きくなる。

文書を開いた時はちゃんと元画像のファイル形式は展開されているので文書上でもスクロールが軽い。
本当はPNGを更に不要なデータを削除するソフトもあって、フォトレタッチでPNG化して更に最適化を掛けるともっと小さくなる。
ただ、GIFやPNGを多用すると、多数のページがあるPDFを開いた時にスクロールがコマ送りになるくらいモッサリしてしまう上に、これ以上圧縮できないくらいに最適化されているのでBitmapの256色として保存した文書より巨大化してしまうことも多々ある。

ここで紹介しているComposerマニュアルVer4(最終版)も第4段を最後に極められる所まで極められた(2005年4月当時)訳だが、使用している画像は全てBitmapで、本来の文書のサイズなんてバラにすると軽く30MBにもなる。それも配布される時にやれるだけの最適化を施してあるので、62ページフルカラーのマニュアルでさえも6.2MBで済んでいる。

もうひとつ。ウェブ上のコンテンツでは、サムネイルとしてのキャプチャーは全て実寸で使用して、必要に応じて文書内で縮小しよう。なぜなら、キャプチャーは殆ど色を使っていないのだが、画像そのものを使用する前に縮小してしまうと大量の中間色が発生して、元の画像で使われている色の数を大幅に上回ってしまう。でも、実寸の画像を文書内で縮小すれば、元の画像だから綺麗に表示される上に容量も下手に増やすことなく綺麗なままの画像を表示できる。

これはPDFビューワの画面上で縮小拡大してみると違いが出ることに気づくだろう。
これさえ守れば、画像タップリのPDF文書も配布時には思いっきり少ない容量になった版で配布できるのだ。

ただ、表示/印刷した時の美しさではSVG形式には絶対に勝てない。しかも線と塗りつぶしの情報で出来ているSVGはテキスト形式のデータの絵であるため、非常に圧縮にも優れている。
図解などでワードアートやオートシェイプ(OOoではフォントワークや図形描画という)をなるべく使うようにすると、同じ矢印のイメージでも、SVGではいくら拡大・縮小しようと画像の品質は変わらない。
反面、多用しすぎたり、一画面に大量のSVGを埋め込むと閲覧が重くなるのでやりすぎには注意が必要。

ウェブサイトでもPDFでも、使いどころによって最適な画像形式を最適なサイズとファイルタイプで加減するのは、見る側に与える印象も違う。勿論、ウェブサイトでは予め画像を縮小した方が良いし、使い分けで一番ファイル容量が小さい画像をその都度選択する必要はある。

0 件のコメント:

コメントを投稿