しらぎくイメージライブラリの応用例・PNG画像非対応ブラウザへの画像変換機能。

ここでは、GIF画像/JPEG画像/PNG画像相互間の変換を行なうPerlスクリプトしらぎくイメージライブラリの実際の応用例として、PNG画像に対応しない古いブラウザに対してPNG画像をGIF画像に変換して配信する機能について解説しております。

おことわり。(平成17年12月20日)

当サイトでこのシステムを実験的に稼動しておりましたが、平成17年12月20日限りで実験を終了し、このページでの見本を除く当サイト内のPNG画像も全てGIF画像に戻しました。

以下の記述は導入時点でのものです。現在では上記の通りこのページ以外ではシステムは発動されません。

どんな機能か。

WWWサーヴァにしらぎくイメージライブラリを用いて作ったPNG画像からGIF画像への変換CGI設置して、.htaccess設定ファイルでPNG画像に対応しないウェブブラウザがPNG画像をリクエストしてきた場合は変換CGIの呼出しに読み替える事で、自動的にPNG画像をGIF画像に変換して配信出来るようにします。

この方法を用いる事で、PNG非対応環境を本当の意味で気にする必要無くPNG画像をサイトに利用する事が可能になります。

ここでは、当サイトで実験的に用いた方法を解説させて頂きます。

目次。

  1. PNG画像を利用するにあたって 〜前書き〜
  2. 作るべき処理の流れ
  3. WWWサーヴァの条件

  4. 実際に組込むシステム

    1. 実際に組込む「PNG画像からGIF画像への変換CGI」
    2. .htaccess設定ファイルでの設定
  5. 制作者の実際の使い方
  6. 実際に表示させたPNG画像のサンプル
  7. 補足事項
  8. アンチPNGである制作者 〜後書き〜

PNG画像を利用するにあたって。〜前書き〜

このページで紹介する事は、傍目に見れば面倒な事をしていると思われるかも知れません。

何でこんな面倒な真似をしてまでPNG画像を導入する意味があるのかと思われるでしょう。

確かに、ユニシス社の特許問題も解消された今日では、無理してPNG画像にする必然性もありません。

PNG画像を導入する事で得られるメリット。

しかし、PNG画像にはGIF画像と較べて、以下のような利点があります。

GIF画像に較べて、小さくなる場合が多い

制作者が調べたところ、インデックスドカラーでは殆どの場合でGIF画像よりPNG画像の方が小さくなりました。

場合によっては二割以上の削減もありました。

勿論、逆にPNG画像の方が却って重くなってしまう場合もあり得ない事ではありませんが、そのようなケースは八色以上のインデックスドカラーでは殆どありません。

サーヴァの転送量の問題やより早いページ表示の可能性を考えると、リソースは少しでも小さくしたいもので、PNG画像形式はそのような需要に向いていると言えます。

フルカラーも使える

この点は制作者にとっては全くと言って良いほど利点を感じません。

なぜなら、フルカラーが必要なら画質を気にしなければJPEG画像の方が小さくなって良いからです。

GIF画像には無い機能が使える

特に有名なのはアルファチャネル(インデックスドカラーの場合はパレット透過度)でしょう。

この機能はGIF画像にはありません。

また、ガンマ値指定なども、対応している環境には有利な機能です。

PNG画像を導入する事で生ずる問題点。

しかしながら、PNG画像を導入すると以下の問題が生じます。

PNG画像は後発の画像形式のため、対応していない環境が残っている可能性がある

勿論、端数を四捨五入すれば現在では100％の実装率と言えます。

しかしながら、制作者は例え 1％に遙か及ばなくても、そのような環境でアクセスされている事実を考慮すると、どうしてもそのような環境を見限る事が出来なかったのです。

ツールによってはPNG画像形式では却って問題が起こる

これはツールの問題ですが、実際PNG画像を作るとGIF画像より重くなってしまったり、インターネットエクスプローラなどで開けないものが出来てしまったりします。

制作者はそう言うツールを使っていました。

そこで、GIF画像を別の信頼出来るツールでPNG画像に変換するというやり方を採りました。

特に、前者は制作者にとっては絶対に看過出来ない問題でした。

結論。

纏めますと、制作者は

このため、PNG画像形式への転向を永らく控えていました。

しかしながら、今回しらぎくイメージライブラリを用いた画像変換機能をサーヴァに実装する事が出来るようになり、或いは実装出来る環境を手に入れられた事に依り、PNG非対応環境を本当の意味で気にせずにPNG画像の利用をはかれるようになったのです。

作るべき処理の流れ。

以上の機能、すなわち

機能を実現するには、以下のようになります。

  1. HTTP要求ヘッダのACCEPTフィールドやUSER_AGENTフィールドでPNG画像に対応しているかどうかを調べる

これだけでしたら、<img>要素のsrc属性に判定CGIのアドレスを書くだけでいい話です。

ただ、それでは余りスマートではありません(この辺には人によって考え方の違いがあるかも知れませんが)。

制作者がいいと思った方法は、<img>要素のsrcには静的なPNG画像のアドレスを記述するものの、PNG画像非対応環境がHTTPでPNG画像を要求した場合に限り、変換CGIを起動して変換すると言う方法です。

これには「.htaccess」設定ファイルで上記の処理を行うように設定する事で実現します。

更に、この際にリダイレクトせずに内部でCGIを起動させる事も可能です。

今回はこの方法に沿ったPNG画像処理方法を解説します。

WWWサーヴァの条件。

以上の機能を実現するシステムの構築に必要なサーヴァ環境は以下のようになります。

必須事項。

WWWサーヴァには以下の条件を満たしている事が必要です。

mod_rewriteを実装している『アパッチ』サーヴァ
当サイトでは平成17年11月22日現在、アパッチ 2.0版を用いております。
ルート権限を持つか、.htaccessを許されている設定がされている事
当サイトは準専用サーヴァ(VPS)のためルート権限があり、サーヴァの設定が自由に出来ます。
Perl 5.xを実装している事
このスクリプトを利用した変換CGIには不可欠です。

推奨事項。

また、以下の条件を満たしている事が望ましいです。

Perlがzlibを実装している事
しらぎくイメージライブラリにはzlib互換の代用スクリプトがありますが純Perlのため処理時間が掛かります。出来るだけzlibを用いたいものです。

実際に組込むシステム。

実際に組込む「PNG画像からGIF画像への変換CGI」。

「PNG画像からGIF画像への変換CGI」は、制作者の発想が込められているものなので、人によっては異なったものになるかも知れません。

今回はしらぎくイメージライブラリのうち、「config.pl」「png2gif.pl」「readPNG.pl」「putPNG.pl」及び「Deflate.pl」だけを抜き取って組込みます。

#!/usr/bin/perl

#パラメータの読込。
$addr=$ENV{'QUERY_STRING'};
$addr=~s/%([a-fA-F0-9][a-fA-F0-9])/pack("C", hex($1))/ego;
$addr=~s/[<>\|]//g;
$addr=~s/\.\.\///g;

#外部参照は拒否する。
if ($ENV{'HTTP_REFERER'} ne '' && !($ENV{'HTTP_REFERER'}=~/サイトのドメイン\//)) {
    print "status: 403 Forbidden\n\nERROR!";
    exit;
    }

#PNG対応環境には配信しない。
if ($ENV{'HTTP_ACCEPT'}=~/image\/png/i || ($ENV{'HTTP_USER_AGENT'}=~/MSIE (\d+)/ && $1>4) || $ENV{'HTTP_USER_AGENT'}=~/Sleipnir/) {
    print "location: http://サイトのドメイン/$addr\n\n";
    exit;
    }

#PNG画像以外は処理しない。
if (!($addr=~/\.png\Z/i)) {
    print "location: http://サイトのドメイン/$addr\n\n";
    exit;
    }

#実際の変換処理。
require './png2gif.pl';
$i=&img::png2gif($addr);
binmode(STDOUT);
print "content-type: image/gif\ncontent-length: ".length($i)."\n\n".$i;
exit;

このスクリプトでは、対応環境が呼出してきた場合には、当該リソースを直接表示させるようにしております。

.htaccess設定ファイルでの設定。

制作者の場合、mod_rewriteが組込まれていたため、これを利用する事で、非対応環境でもURLが変わらないようにしました。

以下の記述をルートディレクトリの「.htaccess」に記述します。

RewriteEngine on
RewriteCond %{REQUEST_URI} !\?
RewriteCond %{REQUEST_URI} \.PNG$ [NC]
RewriteCond %{HTTP_ACCEPT} !image\/png [NC]
RewriteCond %{HTTP_USER_AGENT} !MSIE\s[56789]\.
RewriteCond %{HTTP_USER_AGENT} !Sleipnir
RewriteRule (.*) http://CGI設置URL?$1 [L]

この方法をご覧になると分ると思いますが、インターネットエクスプローラを利用したブラウザで、ユーザエージェント文字列を閲覧者が変更した場合、GIF画像に変換される事になります。

また、mod_rewrite関連の記述は下位ディレクトリには継承されないとの事ですが、制作者の環境では「.htaccess」が無いディレクトリやあってもmode_rewrite関連の記述をしていない場合は継承されているようです。

制作者の実際の使い方。

冒頭でも申し上げた通り、制作者のシステムではこれを更に改良したものを用いております。

具体的には、フルカラーPNG画像の場合はやはりJPEG画像に置換えた方が良いと判断した場合には、代わりのJPEG画像を用意していれば変換しない代わりにそれを配信すると言う機能を搭載しております(現状では実際に使ってはいませんが)。

実際に表示させたPNG画像のサンプル。

PNG画像を実際に表示させると、以下のようにPNG画像対応・非対応のどちらの環境でも表示される事が分ります。

PNG画像に対応しているファイヤーフォックスならPNG画像で表示されます。 一方、PNG画像に対応していないネットスケープ 3.03でもGIF画像に変換されて表示されます。

補足事項。

アンチPNGの制作者。〜後書き〜

PNG画像が現れた背景。

PNG画像形式は、かつてユニシス社がGIF画像形式の基幹技術に関して特許権を行使してきた事を受けて、特許に縛られない規格として策定されました。

反感を生んだPNG画像普及活動と言う名の強要活動。

このような事情から、WWWではかなり熱心な、いや熱心を通り越して狂信的なPNG画像強要活動が散見されました。

しかし、制作者は彼らが展開する余りに強引且つ独善的で気持ち悪い主張を見て、却ってPNG画像(と言うよりPNG画像への切替を強要する連中)にこれ以上無い反感を覚えたものです。

加えて、制作者は後方互換性を出来得る限り維持する主義であり、この点でもPNG画像への転換を受容れる事が出来ませんでした。

GIF画像基幹技術特許問題の消滅がPNG画像導入実験を可能にした。

現在ではユニシス社の特許が失効した事で、このような過激な活動は過去のものとなった事、及びGIF画像を自由に扱えるようになって今回のシステムが完成したため、PNG画像導入を試験的に導入したものです。

言ってみれば、ユニシス社がGIF画像基幹技術の特許権を失ったからこそPNG画像を導入出来たとさえ言えます。

それでも、アンチPNG。

結果は良好でしたが、PNG画像の準備に手間が掛かる事と、今後もアンチPNGでい続けようと思わせる事があった事から実験終了と共にこのページのPNG画像以外は全てGIF画像に戻しました。今後はPNG画像を利用する事はもはや無いでしょう。

おことわり。

尚、当サイトのバナーなど、制作者が配布しているGIF画像に関しては、PNG画像への変換を当然ながら禁止しません。

PNG画像を配布している者の中に、GIF画像への変換を禁止すると言っている者を見た事がありますが、制作者はそんな馬鹿な事は絶対に申しません。

ページ外へのご案内。

本文書でのCSSは正当です。 本文書はXHTML 1.1準拠です。
Copyright (c)平成16年-平成20年　さいたま・しらぎくさいと　版権所有 marguerite.site@gmail.com