お絵描き研究室:PNG(原理編)

新しい画像フォーマットである PNG について、主に対抗馬である GIF と比較しながら解説しています。

1. はじめに

 GIF は 2000 年 3 月現在インターネット上で広く使われている画像フォーマットですが、「お金を払わなければ使えない?」という怪情報が飛び交っています。一方 GIF の代替品として PNG という画像フォーマットがあるらしいのですが、機能が制限される?とか圧縮率が悪くなる?といった疑問が飛び交っています。ここでは両者について比較しながらそれぞれの利点・欠点を明らかにしてゆきたいと思います。


2. GIF について

 GIF は Graphic Interchange File の略で、1987 年に大手アメリカのパソコン通信ネット CompuServe の標準画像フォーマットとして開発されたものです。1bit(2 色), 4bit(16 色), 8bit(256 色)の三種類の色モデルをサポートし 65536 x 65536 ドット(縦横 16bit)までの画像を扱えます。また、ロード中に全体像が表示される インターレース GIF と呼ばれる変形をサポートします。開発当時としては驚異的な圧縮率を誇り、CompuServe の影響力と合間ってまたたく間にアメリカでの標準画像フォーマットの地位を確立しました。
 GIF は 1989 年にフォーマットを大幅に拡張しました。このバージョンを GIF89a、それ以前のものを GIF87a と呼んで区別しています。GIF89a ではヘッダ拡張の仕組みが導入されたため、その後インターネット・WWWの普及に伴って透過 GIFアニメーション GIF などの変形が生まれ、ますます標準画像フォーマットとしての地位を固めてゆきました。しかし、GIF には思わぬ刃が隠されていたのです…。


3. LZW:GIF の隠された刃

 GIF の圧縮の根幹をなすのは LZW(Lampel-Ziv-Welch) と呼ばれるアルゴリズムです。ところが、この LZW 法は Unisys 社が 1984 年に特許を取得していたのです。1987 年の段階で CompuServe は特許の存在について知っておらず(知っていたが黙っていたという説もある)、1989 年の段階で初めて GIF が LZW 特許に抵触することが明らかとなりましたが、Unisys 社は LZW の GIF への応用についてなかなか態度を明らかにしませんでした。
 一般に Unisys のこの態度は「GIF は無償で使う限りフリーライセンスである」と解釈されました。当初は「GIF 画像を生成するのは有料だが表示するだけならフリー」という解釈もあり、GIF 表示機能だけを持ったソフトなら商用ソフトにも使用できるとすら思われていました。しかし、それはきわめて曖昧かつ貧弱な根拠に基づいた希望的観測に過ぎなかったのです。1995 年 1 月 1 日、Unisys と CompuServe は初めて GIF に対する公式見解を発表しましたが、その内容は「GIF を生成ないしは表示する全てのプログラムは LZW の特許に抵触し、Unisys はそれら全てに対しライセンス料徴収の権利を持つ」という恐ろしいものでした。しかし相変わらず有償使用の場合と無償使用(フリーソフト)の場合についての細かい規定などは発表されず、GIF ユーザーは喉元に刃を突きつけられたまま生殺与奪の権利を Unisys に握られる形になったのです(註1)
 Unisys のこの動きに危機感を募らせたプログラマー達は急遽 GIF に代る新フォーマットの制定を目指し、早くも 1995 年 7 月には新フォーマット PNG の概要が発表されました。PNG とは Portable Network Graphic format の略でしたが、暗に PNG is Not GIF との意味も込められていました(しかし、私はスタートレック・ネクスト・ジェネレーション(TNG) のファンが PNG 制定グループに入っていたのではないかと疑っています)。PNG は GIF を超える新しい機能を意欲的に取り込み、フリーライセンスなのでネットワーク上誰でも自由に使える「夢の画像フォーマット」になるはずでした。
 しかし、PNG の普及は遅々として進みませんでした。理由はいろいろあるのですが、一つは GIF があまりに普及しすぎていたこと、Unisys の態度が曖昧すぎてなかなか GIF を見捨てる気にならなかったこと、PNG のオプション仕様が多すぎて全てを実装することが難しかったことなどが理由でしょう。しかし 1999 年末頃から Unisys は更に態度を硬化させ、「非ライセンスのソフトで作られた GIF 画像もライセンス徴収対象になる」「非ライセンスの GIF 画像を発見した場合はそのプロバイダを提訴する」等というヤクザまがいのタカリをやるようになりました。このまま Unisys の勝手を許しておいたらどこまでつけ上がられるかわからない!PNG はこうして、Unisys に対する反発をバネとして急速に普及しだしているのです。
 なお仕様書によれば PNG は「"PING(ピング)" と発音する」そうですが、私は「ピー・エヌ・ジー」と発音する方を好みます。ピングだと Unix の ping コマンドとかペンギンのピングーと紛らわしいです(^^;)。

註1:ここがよく誤解されているポイントなのですが、 2000 年 3 月現在正規に Unisys にライセンス料を支払ったソフトによって作成された GIF 画像そのものの使用について Unisys にライセンス料を支払う必要はなく、特許法の性質から言っても今後この規定が変わる可能性は非常に少ないと思います。しかしアクセスカウンターグラフ表示など、 GIF 画像を動的に生成する CGI としての応用は今後ますます厳しく規制されてゆくでしょう。また、少しでも GIF を表示する可能性のあるソフトウェアは軒並みライセンス徴収対象として槍玉に挙げられる危険性を秘めています。いくら「GIF そのもの」がフリーだとはいえ、これでは「軒を貸して母屋を取られる」ようなものでしょう。


4. PNG について

 PNG は GIF を代替するために作られたものだけに、基本的な機能は GIF に似ています。しかし「GIF を倒すべく」全ての機能において GIF を超えたスペックが設定されています。色数は 2bit, 4bit, 8bit に加え 24bit のフルカラーモードをサポートします。GIF と同じく「透過色」が指定できるうえに、各ビットの透過度を指定できるαチャネル(またはマスクチャネル)をサポートします。画像サイズは GIF の 65536 x 65536 に対し 2147483647 x 2147483647 ドット(縦横 31bit) をサポートします(しかし現在のパソコンでそれだけの大画像を扱うことはないでしょう)。PNG はインターレース GIF に相当する機能も持っていますが、PNG のそれは通称 Adam7と呼ばれるアルゴリズムを採用しており、より効率よくスムースに進行中表示ができるように工夫されています。

 GIF89a がただ一種類のコメント文字列しかサポートしなかった(JFIF もそうだが)のに対し、PNG では「キーワード」と「文字列」をペアとして任意個の文字列を埋め込むことができます。キーワードはユーザーが任意に定義できますが、表1−1に示すキーワードは標準として使用法が予約されています(個人的には「やりすぎ」だと思いますが)。これらは全てオプションであり、PNG 画像への埋め込みを義務づけられている訳ではありません。実際、埋め込みテキストの入った PNG 画像自体あまり多くは出回っていないのが現状です。

表1−1 PNG 埋め込みテキスト・キーワードの一覧
キーワード内容
Titleタイトル(通常は原ファイル名)
Author作者名
Description解説
Copyright著作権表記
Creation Time作成日時
Software作成ソフト名
Disclaimer制限事項
Warning注意事項
Source引用元(通常は URL)
Commentコメント

 実は PNG の埋め込みテキスト(tEXt/zTxt チャンク)には ASCII しか使ってはいけない という嫌な制限があります。厳密に言うと ASCII ではなく iso-8859-1 であり、EUC やシフト JIS が使っている 8bit 後半領域を英数外字に宛てた規格です。しかも iso-2022-jp のようなエスケープシーケンスの埋め込みも認めていないので、この規格を尊重する限り PNG のコメントに日本語は埋め込めません。国際標準規格だなんて偉そうに言っておきながら随分馬鹿にした話です。
 さすがにこれでは気まずかったのか、PNG 1.2 の仕様では UNICODE の変形である UTF-8 を用いた iTxt チャンクが新たに制定されました。しかし iTxt チャンクはいかにも「英語しか知らないアメリカ人が一生懸命多国語化を考えた」ような複雑な構造になっており、ただですら埋め込みテキスト対応ソフトが少ない昨今、iTxt に対応したソフトが揃うには数年の時間が必要に思えます。

 PNG は LZ77 と呼ばれる圧縮アルゴリズムの発展形(通称 Deflate/Inflate)を採用しています。LZ77 は GIF の LZW の原形であり多少圧縮率に劣る傾向があるのですが、PNG では圧縮の前処理としてフィルタ操作を導入することで圧縮率向上を計っています。フィルタとはスキャンライン(画像水平方向の走査)における単純なドット間の差分公式で、フィルタをかけることによってスキャンライン中のピクセル値が平均化され、圧縮効率が上がることを期待しています。PNG では以下の5種類のフィルタを定義しています。

表1−2 PNG フィルタの一覧
名称演算操作
None何もしない
Sub左右ドット間を差分として計算
Up上下ドット間を差分として計算
Average上・左ドットの平均値からの差分として計算
Paeth上・左・左上の中からの直線補完値として計算

 PNG では各スキャンラインごとにフィルタの種類を選択できるため、例えば縦 200 ラインの画像であればフィルタの組み合わせは 5^200 種類にものぼります。とてもこんな物全部は試していられませんので、圧縮時のフィルタ適用アルゴリズムについては各ソフトごとに異なる方法が採られているようです。一般的には上ラインから順に5種類づつ試してゆき各ラインにおいて最も圧縮率の高かったフィルタを使う方法(5^200 ではなく 5*200 通りの組み合わせで済む)、あるいは一種類のフィルタを全ラインに対し適用する方法が取られているようです。

 GIF がヘッダの拡張で機能を増やして行ったように、PNG では全てのデータがチャンクと呼ばれる単位で格納され、拡張が容易な設計になっています。チャンクは CRC によって正当性を検査されるのでデータ化けに対しても安全な設計になっていますが、PNG の実装を面倒にする原因にもなっています。また PNG が GIF に対して決定的に不利な要素として、PNG がアニメーションフォーマットをサポートしない点が挙げられます。これは技術的には充分実現可能なのですが、PNG 規格制定グループが中途半端なアニメーション機能の拡張を嫌っており、別規格である MNG(Multiple Network Graphics) によって実現する、という態度を取っているためです。
 また、画像データに「ガンマ値」を埋め込むことができるのは PNG の大きな特徴です。しかし、これは PNG にとって思わぬ障害にもなり得る二重の刃でもあります…。


5. ガンマ補正、この便利にして厄介なるもの

 ガンマ値(γ)とは画素の輝度レベルと実際に表示される輝度との相関関数です。これが 1.0 であれば輝度レベルと表示輝度は完全に 1:1 に対応しているのですが、現実のブラウン管には「暗い色はより暗く、明るい色はより明るく」映る傾向があり、一般には γ=1.8〜2.5 程度の値となります。もし光学的に完全なスキャナがあると仮定して写真を撮り込んで見ると、肉眼では奇麗な階調に見えた写真がなぜか黒ずんで見えてしまいます。これは原画像では直線だった輝度階調をブラウン管が「歪めて」表示してしまうからです。これを補正するには

(1) 原画像の階調を操作して(明るくして)画面に合わせる
(2) 表示系に階調補正回路を入れ画面表示を原画に合わせる

 という二つの方法があります。通常 Windows マシンは(1) に頼っていますが Macintosh は一部 (2) を使っており(補正後のガンマ値はデフォルト設定で約 1.5 です)、NeXT は完全に (2) を導入して表示系のガンマ値を 1.0 に近似させています。従って Windows で普通に見えていた画像を Mac に持ってゆくと妙に白っぽくなり(補正が二重にかかってしまうため)、Mac で普通に見える画像を Windows に持ってゆくと妙に黒っぽくなってしまい、どちらの画像も NeXT では異様に白っぽい画像に見えてしまうという悲劇を産みます。

 PNG ではガンマ補正値を画像データに埋め込むことでこの問題を回避しようとしています。PNG に埋め込まれるガンマ補正値とは、わかりやすく言えば画像作成に使われた表示系ガンマ値の逆数です。例えばγ=2.0 の Windows で作られた画像には補正値として 0.5 が埋め込まれており、これをγ=1.5 の Macintosh で表示すると補正後のガンマ値は 1.5 * 0.5 = 0.75 となり「若干暗め」に表示されることになります。γ=1.0 の Next では補正後のガンマ値 0.5 によって「かなり暗め」に表示されることになります。なお、PNG の仕様書では PC 用の標準補正値として 2.20 の逆数 0.454545... が推奨されています。

 …理屈ではこのようになっているのですが、なかなかガンマ値というのは厄介な奴です。そもそも印刷業界や映像業界にでも関わっていない限り「ガンマ」なんて言葉を知っているユーザーなんて多くはいません。モニターやソフトの側でガンマ補正を設定できる機能があっても使っていなかったり、ひどい場合には間違った設定で逆効果に使われている場合も(結構)あります。プログラマーとても大同小異。PNG が規格としてガンマ値を定義しても、その値を出力する PNG 作成ソフトウェアやそれを表示する PNG 表示ソフトウェアが正しく対応していなければ、ガンマ補正によって階調が正しく表示されるどころか逆効果になってしまう恐れがあります。恐れどころか、これは今現実に起こっている PNG の問題なのですが…これについては次章で実験してみます。


6. 多すぎるオプション:この頭痛の種

 PNG は多くのオプションを持ちます。多すぎて頭が痛くなるくらいです。例えば色数について上では「2bit, 4bit, 8bit に加え 24bit」と書きましたが、厳密に言えば「1ピクセル 1, 2, 4, 8, 16bit それぞれの色深度について グレイスケール、パレット、RGB の3種類の色モデルをサポートする」です。この定義において有意な組み合わせは15通りにのぼり、これにαチャネルの有無が加わると色表現形式だけで30通りものフォーマットが存在することになります。しかも「どれとどれが必須であとはオプション」という扱いがないので、「PNG 対応」ソフトは少なくともこれら全てを読み込み表示できなければならないのです。

 また PNG において透過色の指定は色モデル(グレイスケール、パレット、RGB) に対応した3種類のフォーマットが定められています。しかもパレットカラーの時だけ複数の透過色(1〜パレット数まで)が指定でき、しかも各色ごとの透過度が指定できるようになっています。そんな中途半端な事をする位なら素直にαチャネルを指定すればいいと思うのですが…。PNG の透過モデルは(恐らく必要以上に)高機能を狙いすぎ複雑怪奇になったため、透過 GIF のようには簡単に実装できなくなってしまっているのです。

 PNG には透過色とは別に「背景色」を埋め込むこともでき(これも各色モデルに対応した3つのフォーマットがあります。しかし一体何に使うのでしょう?)、ガンマ補正値だけでなく色温度やヒストグラムを埋め込むこともでき、原画像のビット深度を埋め込むこともできます。PNG の埋め込みコメントは圧縮することもでき(zTXt)、新しい iTxt は圧縮の他に多国語化することもできます。なるほど至れり尽くせりのよく考えられた素晴らしい規格ではあります。PNG 制グループは「GIF の代替品」を作ろうとしたのではなく、従来に存在した画像フォーマット全てを置換し得る汎用(Universal)な画像フォーマットを作ろうとしたようです。

 しかし世の中には「帯に短し襷に長し」という諺もあるのです。PNG に定義されたオプションの数々は単にアイコンを表示するためには大袈裟すぎ、本格的な画像編集ソフトに使うには貧弱すぎるのです。もちろん PNG のチャンク構造は柔軟な拡張を許しているので足りない機能は後から新しく追加することもできますが、それなら何故一番最初の仕様(PNG 1.0)をここまで肥大化させる必要があったのでしょうか?
 PNG の最初の目的は GIF を置換することであり、そのためには PNG 対応プログラムが簡単に作れるよう「実装の容易さ」というファクターを重視するべきだったのではないでしょうか。その反面これだけの多機能を詰め込んでおきながら GIF の強力な武器であるアニメーション機能についてだけは知らん振りをするというのもおかしな話です。PNG 制定グループは閉じた価値観の中で理想主義に走りすぎ、インターネットの現実と GIF を駆逐するという本来の目標を見失ってしまったのではないでしょうか。


7. まとめ:GIF と PNG について

 今まで述べてきた GIF と PNG の比較を表1−3に示します。

表1−3 GIF と PNG の比較
項目GIFPNG
制定年度19871995
圧縮方法LZWLZ77
ライセンスUnisys が保持フリーライセンス
色数2/16/256 色2/16/256/1677万色,その他
解像度最大 65536 x 65536最大 2147483647 x 2147483647
インターレースありあり(Adam7 アルゴリズム)
背景透過ありあり
透過度指定(αチャネル)なしあり
アニメーションありなし(別枠規格 MNG で定義)
コメント埋め込みあり(GIF89a)あり(キーワード付き)
ガンマ補正値埋め込みなしあり


[PNG(実践編)]へ続く…


[研究室] [目次]
Copyright by 'Crazy' Y.Sasaki
Web Hostingweb hostingdedicated serversSSL Certificatedomain namesweb hosting