カテゴリー別アーカイブ: 汎用テク覚え書き

IE7.jsを使ってInternet Exploler 6でのPNGの透過指定を有効にする

前回エントリで述べたPNG形式の優位性、アルファチャンネル使用による透過ですが、Internet Explorerではヴァージョン7からの対応となり、それ以前のヴァージョンでは透明部分が灰色に表示されてしまうなど上手く表示されません。ブラウザシェアの全世界および国別割合がわかるこちらのサイト(http://gs.statcounter.com/)の数字を見ると、代表的な未対応ブラウザであるInternet Explorer 6のシェアが、2012年1月現在全世界で約1.6%、日本で約2.3%であることがわかります。数年前に比べればあまり大きな割合ではないので対応を放棄してしまうというのも十分ありなのですが、もし手間をかけず対応させたいのであれば、Googleの公開しているIE7.jsを利用するのが便利です。

IE7.jsの概要

IE7.jsは、古いヴァージョンのIE(5.5〜)に新しいヴァージョンのIEの機能を提供する目的で作られたライブラリで、拡張子に.jsと付いていることから判るように、JavaScriptのライブラリです。ですが使用にJavaScriptの知識は必要なく、html文書のヘッダ部でリンクを明示するだけで使用できるようになります。

(2012.6追記:この部分の画像は000webhostに接収されてしまいました)

上のコードの赤字部分が必要なコードになります。透過PNG対応の話からは余談になりますが、同様に以前のヴァージョンのIEをヴァージョン8相当および9相当にする、IE8.js、IE9.jsというライブラリも存在します。それらを呼び出す場合には、一行目のIE 7の部分を呼び出すヴァージョンに、二行目のアドレスの末尾をIE8.jsやIE9.jsに変えてください。

さて、ライブラリの宣言が終ったら、透過を有効にしたいPNGファイルの末尾に-transを加えて保存してください。上の例では、titleimage.pngというファイルの透過を有効にしたかったので、titleimage-trans.pngとリネームして保存しています。これで必要な作業は終わりです。

注意点があります。まずこの機能は閲覧者がJavaScriptを有効にしていないと働かないということ。そして、透過PNGを背景画像として使用した場合にbackground-repeatやbackground-positionが上手く機能しなくなってしまうという点です。前者については、そもそも再三の注意喚起にも関わらずIE6を使い続けている(使い続けざるを得ない)閲覧者がJavaScriptを有効にしているのかという疑問がありますし、後者の仕様などは、うっかり見落としてIE6での見え方が大変なことになったとして、それを確認できる環境がページ作成者の手元に揃っているとは限らないため問題が長く放置されてしまう可能性が高くなるのが困りものです。

ということで、透過PNGをレイアウトに使いたい場合にIE7.jsを使うか、それともIE6はお断りと但し書きをするかについては、最初に提示したIE6のシェアも加味して結論を下しても良いのではないかと思います。仕事の場合であれば、クライアントが依然IE6を使っていそうだったらしっかり対応するといった具合で良いのかもしれません。


GIF形式とPNG形式それぞれの透過の実現

前回の予告通り、GIF形式とPNG形式それぞれの透過についての説明です。

GIF形式での透過 〜クロマキー合成

GIFの画像で透過を実現する場合には、映像制作でいうところのクロマキーの手法を使います。よくテレビ番組の制作現場で、俳優が青い背景をバックに撮影を行い、のちに別撮りした背景と合成するという方法がとられていますが、同じことをインデックスカラーを使って表現します。映像の合成の場合、青色の背景が使われるのは俳優の衣装や肌の色とかぶりにくいからですが、GIF画像の場合も、画像の中で使われていない色をカラーマップで宣言し、透明にしたい部分に敷き詰め透過色とします。8ビットで宣言できる256色のうち1色が透過色になるので、画像自体の最大色数は255色になります。

PNG形式での透過 〜アルファチャンネル

GIFの代替形式としてインデックスカラーを採用したPNG-8の場合は、やはりクロマキーの方法で透過を表現します。一方PNG-24の場合は、フルカラーの表現に必要な24ビットに加えて8ビットのアルファチャンネルを持つことで、完全な透過のみならず半透明のような段階的な透過の表現ができるようになっています。

アルファチャンネルについて、わかりやすく図式化します。

アルファチャンネルの説明

クロマキー合成を使う場合、使うビット数が1ビットなので、そのドットが不透明かそうでないかという2値しか表現できません。それに対してPNG-24のアルファチャンネルを使えば、そのドットの透明度がどれ程なのか、分母を8ビット=256にした数値で表せます。たとえば128/256ならば、そのドットの透明度は50パーセントであり、そのドットが重なった下の要素が半分程透けて見えるということになります。

以上の違いをふまえると、段階的な透過を用いたレイアウトをしたい場面ではアルファチャンネル付きのPNG-24を使用するのが適当であり、レイアウト的にそれが必要ない場合では、画像のサイズを不必要に増やしてしまわないよう8ビットのフォーマットを採用するのがよいと判断できます。

とは言え、高性能なアルファチャンネル付きPNGは古いブラウザに対応していないというのも実状です。そこで次回のエントリではそれを解決するウラ技を紹介してみたいと思います。


もう少し突っ込んだGIFとPNGの話

前回はGIFとPNGの機能差について、いくつかの項目を挙げて説明としました。予定ではその次のエントリで両形式の透過の実現について書くつもりでしたが、前回の説明で言葉足らずな部分があったことに気付いたので、このエントリを補足とさせていただきます。とりあえず両形式の使い分けについてだけ知りたい方は、このエントリを飛ばして前後のエントリを参考にしてください。

ビット配列による色表現

基本的な部分にたちかえってみますと、デジタルの画像データはつまるところ1または0の値をもったビットの集まりになります。色の表現の考え方としては、1ドットにつき1ビットの情報をもつことができるのならば、そこに色があるか/ないかを情報としてもてるわけで、単色の画像を表現できます。この場合の単色は白黒に限らず、もし1を、”赤色が存在している”ことの指標として定義しているのなら、この1ビットの画像は赤白になるはずです。宣言は画像データの内部や、あるいはデータを読み込むソフトウェアのどこかでされているはずですが、その場合でも1ドットについてみれば1ビットのデータしかもっていないので、1ビットのビット深度をもつ画像と呼ばれます。

次に、2ビットのビット深度をもつ画像について考えてみます。2ビットのデータというのは、00、01、10、11という四種類の値をもつので、1ドットにつき4色を表現できることになります。例として、赤、茶色、焦げ茶色、群青色の四色を使う場合を考えてみましょう。どの値にどの色を割り当てるかという情報は、先ほどの赤白画像の例と同じようにどこかで宣言されていなければなりません。この例の場合00=赤、01=茶色、10=焦げ茶色、11=群青色のような宣言をするのですが、このビット配列と色の対応表をカラーマップと呼びます。一方、ドットごとにカラーマップのどの色を使うかの宣言部分は、たとえば赤が3ドット並んだ後茶色のドットが1ドットある場合、00、00、00、01のようになります。この宣言部はインデックスと呼ばれ、このようなカラーパレットとインデックスを使った表現方式をインデックスカラーと呼びます。

インデックスカラーの特長として、画像ファイルのサイズに見合った効果的な色表現ができることが挙げられます。たとえば青空を撮影対象とした写真では、使われている色はほとんど青や水色です。もし8ビットのビット深度をもつ画像が、赤から青、緑までまんべんなく色を備えていたとしたら、その中で使う色はたかだか10種類くらいで、残りの200色以上の定義色が無駄になってしまいます。理想としては青系統の色で数十段階用意されていた方が、より自然に青空を表現できます。その点インデックスカラーではカラーマップに自由に色を当てはめることができるので、青空の画像のような例では8ビット、つまり256色でも後述のフルカラー画像と遜色ない表現が可能になります。

インデックスカラーは確かに少ないビット数での色表現に向いていますが、画像のビット深度が大きくなるにつれ、今度はカラーマップの定義部分が無視できないサイズになってきます。理屈では24ビットのビット深度をフルに使う場合、たとえ青空のみの画像でも1680万色弱を定義しなければなりません。そこでビット深度の大きい画像では、ドットあたりのビットデータを3等分し、rgb(赤、緑、青)それぞれの色を段階的に定義、その混色で色を作り出すという方法がとられます。この方法はダイレクトカラーと呼ばれ、特に24ビットをrgbの各色8ビットずつで分割し定義したものはフルカラー画像と呼ばれ、標準的なフォーマットになっています。

GIFとPNGの採用方式の違い

さて、GIFとPNGの比較に戻ります。GIFが通信環境の貧弱な時代に策定された形式であることは先述のとおりですが、そのため採用されている色表現の方式はインデックスカラーです。一方のPNGでは、GIFの代替フォーマットとして普及を狙ったという経緯から、8ビットのPNG-8でインデックスカラーを採用しています。PNGはGIFに比べてサイズが大きいというイメージがありますが、GIFと同じ256色に減色を行うPNG-8で保存すれば、サイズは多くの場合PNGの方が小さくなるようです。

PNGはまたダイレクトカラーもサポートします。ビット深度に応じてPNG-24、PNG-48などフォーマット名に接尾語がつきますが、よく使われるのはフルカラー画像のPNG-24およびPNG-32です。ただしソフトによってはこうした接尾語つきの呼び方を使わず、一様にPNGとして扱ったり、PNG-32をアルファチャンネル付き24ビットPNGと表現したりと呼称に揺れがあるので、WEB上の解説でも混乱が生じているという印象があります。今回のエントリでビット配列にまで踏み込んだ解説を行ったのは、そのあたりの混乱をある程度解消することを狙ったものですが、次回のエントリの透過の説明とあわせて、呼称の揺れに対してある程度のあたりをつける材料となってくれることを期待しています。


GIF形式とPNG形式の使い分け

WEB制作でよく使われる圧縮画像形式としては、写真などに高い圧縮率を誇るJPEG形式と、イラストなどの色の少ない画像に最適なGIF形式、PNG形式があります。JPEG形式とGIF、PNGとの使い分けは上に書いた通り、対象が使用色が少ない画像かどうかによって決定することができますが、ではGIF画像とPNG画像の使い分けはどのようにされるべきでしょうか?今回はそれについて纏めてみました。

まず、両形式が普及した背景を眺めてみます。GIF形式の登場は20年以上前で、当時通信速度の遅かったパソコン通信でサイズを減らして画像のやり取りをする必要性から普及しました。通信速度の制限に加え、当時のパソコンの処理速度的な問題から24bitフルカラー画像は扱いにくかったため、GIF画像には最大256色という制限が設けられています。

対するPNGは、GIF形式の特許問題が浮上した15年程前に開発が始められました。フルカラーに対応、透明度の設定が可能などGIFよりも多くの機能を持っていましたが、本格的な普及は2000年代前半以降になります。丁度この頃にGIFの特許の適用範囲が拡大され、一般のWEB制作者にも特許問題が無縁ではなくなってきたため、GIF利用者が流れるようにPNGに移行し、PNGはWEBの標準フォーマットとしての地位を確立するに至りました(現在ではGIFの特許が失効しているため、制作者がGIFを避ける風潮はなくなっています)。

以上が両形式の登場背景ですが、こうした登場背景の違いに由来して、次のような差異が存在します。

  • PNGがフルカラーに対応しているのに対し、GIFは基本的には非対応
  • GIFは初期のWEBブラウザでも対応している。PNGは1997年頃以降からボツボツと対応
  • iモードのブラウザでは(おそらくフルカラー画像によるパケット増大を避けて)PNG不可

一方で両者は規格の性質にも多少の違いがあり、PNGはGIFの単純な上位互換というわけではなくなっています。たとえば、GIF形式は複数の画像をセットにして1ファイルにすることができます。この性質を利用して複数画像をパラパラ漫画のように使ったのがアニメーションGIFですが、PNGはアニメーションをサポートしておらず、機能拡張板であるMNGやAPNGといった規格が別に存在しています。

  • PNGはアニメーションに対応していない

先ほど、GIF形式は基本的にはフルカラーに対応していないと書きましたが、このアニメーション機能を力技的に利用すれば、フルカラーの画像をつくり出すこともできます。フルカラーの画像を256色ずつ数枚の画像に分離して、短い時間間隔で表示する方法です。しかし、本当に初期のブラウザや携帯のブラウザは、そもそもアニメーションGIFに対応していなかったり、表示枚数に制限があったりするので、この技は万能ではないということにも注意する必要があります。

透明部分を持った画像の実現方法にも、興味深い違いを見て取ることができます。詳細については次のエントリに書きますが、後発の規格であるPNGの方が柔軟な方法をとっており、総じて次のようなことが言えます。

  • 透明部分がある画像については、PNGを使っておいた方がなにかと便利である
  • 透明PNGは古いブラウザでは対応していないが、力技的に対応させることが可能である

以上のような判断材料から、GIFとPNGの使い分けを考えればよいということになります。勿論それぞれをサイト上の適材適所で用いればよいのですが、複数の画像フォーマットが混在して画像リンクの設定ミスが起こってしまう(.gifの拡張子のところを.pngにしてしまうなど)ことを避けるために、どちらかの形式に統一しておくということもひとつの考え方です。


プログラム・設定ファイルのコメント書式一覧

個人的によく使うプログラミング言語・設定ファイルのコメント書式を、まとめてメモしておこうと思います。

コメント書式一覧
言語・設定名 コメントの書式 備考
XHTML(HTML)・HTML5 <!‐‐ ここにコメントを書く ‐‐> 複数行も可能です。コメント中の連続したハイフン(‐‐)の使用は禁止されています。
CSS /* ここにコメントを書く */ 複数行も可能です。
PHP // ここにコメントを書く 一行のコメント。複数行はダメ。C++形式。
#ここにコメントを書く 一行のコメント。複数行はダメ。ShellやPerl形式。
/* ここにコメントを書く */ 複数行も可能です。
JavaScript・ActionScript // ここにコメントを書く 一行のコメント。複数行はダメ。C++形式。
/* ここにコメントを書く */ 複数行も可能です。
Objective-C・Swift // ここにコメントを書く 一行のコメント。複数行はダメ。C++形式。
/* ここにコメントを書く */ 複数行も可能です。
SQL ‐‐ ここにコメントを書く 一行のコメント。複数行はダメ。
/* ここにコメントを書く */ 複数行も可能です。
php.ini(PHPの設定ファイル) ; ここにコメントを書く 一行のコメント。複数行はダメ。
.htaccess(サーバアプリケーションの設定ファイル) # ここにコメントを書く 一行のコメント。複数行はダメ。

これからもうちょっと複雑なWEB制作を始めたら、表の項目が増えていく可能性もあります。そして、間違っている箇所を発見したら指摘していただけると非常に助かります。


サイトデザイン初歩の初歩

非常に単純なことなのですが、サイトのGUI部品、タイトルロゴなどの青写真を組み立てるとき、頭の中で考えるよりまずブラウザが立ち上がってるスクリーンショットを保存し、画像編集ソフトのレイヤーにする。その上で部品のデザインを行い配置していく。

恥ずかしながらこれに気付くのに結構かかりました。紙にデザインを描いて、実際画面上でラフ画のイメージが再現されないのは自分の技術不足だと勘違いしていたのですね。

携帯を持っているのに電卓を探して部屋中うろうろしていたような、そんな感じです。