PNG画像形式の概要。
- 平成16年 9月18日 開設
- 平成19年 4月24日 更新
PNG画像形式について解説します。
- 制作者はアンチPNGですが、公正さを欠かない解説をしております。
PNG画像とは。
PNGとは「ポータブル・ネットワーク・グラフィックス」の略で、GIF画像の基幹技術であるLZW圧縮アルゴリズムに特許問題が絡んだために、GIF画像及び同様にLZW圧縮を利用しているTIFF画像形式(ウェブでは使われないが、印刷用などオフライン向けの画像ではよく利用されている)を置き換えるためのパテントフリー(特許無問題)の規格として、西暦1996年(平成 8年)に策定されました。
- LZW圧縮の特許は既に失効しておりますが、当時は相当問題になったものです。
PNG画像形式の主な特徴は以下の通りです。
- 特許無問題の技術として有名なデフレート圧縮(LZ77圧縮…GZIPやZIPなども採用)を採用しており、特許問題の心配がありません。
- 256色までのインデックスドカラーに加えて、グレイスケールやフルカラーにも対応しております。
- GIF画像同様かなり小さく圧縮させる事が出来、圧縮されたデータは元通りに展開される可逆圧縮となります。
- フルカラーの可逆圧縮は極めて効率が悪いため、少しでも効率よく圧縮出来るようにフィルタと呼ばれる事前処理を行っております。
- 透過のみならず、半透明も可能です。特にフルカラー及びグレイスケールではアルファチャネルと呼ばれる、ピクセルごとに透明度を指定する機能も利用出来ます。
- アルファチャネルは、もじら 1.0以降, オペラ 6以降, マッキントッシュ版インターネットエクスプローラ5.x及びサファリは対応しておりますが、ウィンドウズ版インターネットエクスプローラでは7.0以降になって漸くサポートが決まったと言う状況です。
また、インデックスドカラーでもパレットごとに透過度が指定出来ます。
- 後発の技術のため、サポートが遅れておりました。特に携帯電話ではシェアが圧倒的なｉモード端末は今もってサポートしていないため、かなり不利な状況にあります。
- PC向けのブラウザでは既に端数を四捨五入すれば100％の普及率です。
- 複数の画像を一本のファイルに纏める事は出来ません。この結果、アニメーションは不可能となり、これがPNG画像の普及を遅らせた最大の理由となりました。
- その後、PNG画像を拡張した動画形式MNG(ミング)も策定されましたが、ブラウザに対応してもらえない事に加えて、アニメーションGIF画像とフラッシュが既に動画形式としてウェブを席捲している現状から普及には至りませんでした。
- 主に、ベタ塗りの多い画像(漫画風)の圧縮に最適です。
PNG画像は策定されて以来、ISOなどの国際規格にもなっておりますが、現実には当初の目論見通りにGIF画像を駆逐する事が出来ないままLZW圧縮アルゴリズムの特許権失効を許してしまい、現在でもGIF画像の牙城を崩せないでいるのが実情です。
- これにはPNG画像に関するいろいろな誤解があるように思われます。
PNG画像形式のフォーマット。
PNG画像ファイルは、シグネーチャと呼ばれるヘッダ部と、幾つかのチャンクと呼ばれるブロックから成ります。
シグネーチャ。
シグネーチャとは、直訳すると「署名」と言う意味で、PNG画像ファイルの先頭に付くストリングです。
具体的には、以下のような構成になります。
- 十六進数で[89]
- 「PNG」の文字列
- 十六進数で[0d][0a][1a][0a]の 4オクテット
画像処理ソフトウェアは、このシグネーチャを確認してPNG画像と判断します。
PNG画像以外でもシグネーチャに相当するデータは必ずファイルの先頭に入れられており、それらは形式によって異なるため、画像処理ソフトはそれぞれの特徴に合致するかを調べた上で適切なフォーマットの処理を行います。
- 尚、「PNG」以外のバイナリデータにも仕様書は意味を与えておりますが、ここでは詳細は割愛させて頂きます。
- GIFやJPEGと違って規格のヴァージョンを表すデータは存在しません。
チャンク。
チャンクとは直訳すると「塊」と言う意味で、PNG画像ではデータブロックの事を指します。
チャンクには機能に応じて英字四文字の名前が与えられます。
チャンクの形式は常に一定で、先頭から順に以下のような構成となります。
- データ長( 4オクテット)
- チャンクの本体データのオクテット数です。
- チャンク名( 4オクテット)
- チャンクの機能に応じて与えられた英字四文字の名前です。
名前の大文字小文字にはそれぞれに意味があります。
- 一文字目が大文字なら必須とされるチャンク、小文字なら使用を義務付けられていないチャンクです。
- 二文字目が大文字なら仕様書で公開されている公式なチャンク、小文字なら非公式・私的なチャンク(署名や電子透かしなど)です。
- 三文字目は常に大文字となります。三文字目の扱いは未定義だからです。
- 四文字目はPNG画像ファイルを編集する際にそのままコピーして大丈夫なら小文字、そのままコピーして取出した場合に動作が保障出来ないものは大文字となります。
- 本体データ(任意オクテット)
- チャンクに収録されるデータの本体です。
- CRC( 4オクテット)
- CRCとは、チャンク名と本体データが正常に書かれているかを確認するチェックディジットの事です。
CRCの算出法は仕様書で紹介されております。
最低限知っておきたいチャンク。
PNG画像には幾つものチャンクが仕様書で定義され、また仕様書に無い機能を持たせた私的なチャンクを定義する事も出来ます。
このうち、PNG画像における主要なチャンクは以下の通りです。
- この他にも仕様書には幾つものチャンクが定義されておりますが、デコーダは必須とされるチャンク以外はサポートしなくても構わない事となっております。
- そしてサポートしていないチャンクを見出した場合、チャンクの形式により適切に読み飛ばす事が可能になっております。
IHDR(必須チャンク)…ヘッダ。
IHDRチャンクはPNG画像シグネーチャの直後に現れるべき必須チャンクです。
画像の大きさ、色深度(ピクセルを表現するのに必要なビット数)、カラー/白黒の区別、圧縮形式、フィルタ形式などが収められております。
具体的には以下の順にデータが収められます。
- 幅( 4オクテット)
- 横のピクセル数が入ります。
- 高さ( 4オクテット)
- 縦のピクセル数が入ります。
- 色深度( 1オクテット)
- 1ピクセルを表現するのに必要なビット数を入れます。
値は 8または 8の倍数か約数となります。
- GIFなどに対応するインデックスドカラーの場合、 1( 2色), 2( 4色), 4(16色)または 8(256色)が入ります。
- カラータイプ( 1オクテット)
- カラーか白黒(グレイスケール)の区別、アルファチャネルの有無を入れるものです。
以下の値を加算したものとなります。
- まず、インデックスドカラーなら 1、インデックスドカラー以外は 0にします。
- カラーなら 2を加えます。
- アルファチャネルを利用するなら 4を加算します。
- 圧縮方法( 1オクテット)
- 圧縮方法を指定します。
但し、現行の仕様では 0(デフレート圧縮(LZ77圧縮))以外は定義されていません。
- フィルタ方式( 1オクテット)
- フィルタの方式を指定します。
但し、現行の仕様では 0以外は定義されていません。
- インタレース( 1オクテット)
- 0ならインタレース無し、 1ならインタレース付きとなります。
PLTE(必須チャンク)…パレット。
PLTEチャンクはパレットデータを収めた必須チャンクです。
- 実際にはインデックスドカラー以外では不要となっております。
- フルカラーでは減色する必要がある場合に利用すべきパレット(推奨パレット)を指定しますが、デコーダ側はこれを無視する可能性があります(特に減色しない場合は必ず無視されます)。
- 白黒(グレイスケール)では存在してはいけない事になっております。
後述のIDATチャンクより前に現れていなければなりません。
実際の構成は、一パレットコードはR(赤),G(緑),B(青)の 3オクテットとなり、パレットコード 0番から順にこの形式のデータが並びます。
データの数は、実際に画像で利用されているパレットコードが全部定義される範囲で良い事になっております。
例えば、色深度が 8ビットなら最大256色が使えますが、実際にはパレットコードが17番までしか使われていない場合は 0番から17番までの18組54オクテットのデータを用意すれば良い事になります。
- 但し、画像データ中のパレットコードが定義されている範囲を超えた値になっている場合、エラーとなります。
tRNS(任意チャンク)…透明度。
tRNSチャンクは透過に関する情報を与えますが、インデックスドカラーと他の形式では扱いが異なります。
tRNSチャンクを用いる場合はIDATチャンクの前に、特にPLTEチャンクがある場合はPLTEチャンクとIDATチャンクの間に、設置しなければなりません。
インデックスドカラーの場合。
インデックスドカラーでのtRNSチャンクはパレット毎の透明度を指定するチャンクです。
PNGの最大の特徴となっているアルファチャネルは全ピクセルにそれぞれ指定する必要があり、当然画像データを肥大化させる事になります。
特定のパレットコードに特定の透明度を設定したい場合(GIFの透過機能に対応する機能を実現する場合など)は、アルファチャネルの代りにtRNSチャンクで透明度を指定する方が効率がいいと言う事になります。
各パレットコートに対して、 1オクテットのデータが与えられます。データは０にすると完全透明、255だと不透明となります。
尚、実際に利用しているパレットコードの数より少ないデータでも構わない事になっており、その場合対応するデータの無いパレットコードは255(不透明)と見做します。
IDAT(必須チャンク)…画像データ。
IDATチャンクは画像データを表すチャンクです。
画像ソフトや圧縮ルーティンの都合により、複数のIDATチャンクに分割しても構わない事になっておりますが、その場合分割されたIDATチャンクは必ず連続させなければなりません。
- 一つの画像データを複数に分割してそれぞれ圧縮するという事は出来ません。一つの画像は一回で圧縮されなければなりません。
また、複数のIDATチャンクに分割する場合、どのような分割をしても構わない事となっております。
- それこそ、内容が 0オクテットのIDATチャンクを混在させても仕様上は問題ありません(この事は仕様書にて強調されております)。
- PNG画像形式では、一つのファイルに一画像しか納められない事となっており(アニメーションなどが出来ない)、依って複数のIDATチャンクがあっても、それは単一の画像データを分割したものだと容易に分かります。
実際のデータは、IHDRチャンクで指定した圧縮方式で圧縮された画像データとなります。
- 但し、実際にはデフレート圧縮(LZ77圧縮)以外の圧縮方式は定義されておりません。
その他のチャンク。
この他、PNG画像ではgAMAチャンク(ガンマ値…色調の強さ)や、pHYs(ピクセルの縦横比または 1メータ当たりのピクセル数)なども定義されておりますが、対応していないソフトウェア(作成ソフトもブラウザも含む)も多いようです。
- 特に後者はPNG画像がTIFF画像を駆逐するのに必要なチャンクですが、PNG画像作成ソフトでこれをサポートしているものは少ないようです。
加えて、tEXtチャンク(欧米語のテキスト文字列)を用いて文字列を埋め込む事も出来ます(但し、tEXtチャンクはISO-8859-1以外の文字セットは使えないので日本語文字は使えません)。
また、二文字目を小文字にする事で、私的なチャンクを定義する事も出来ます。
この場合、デコーダには無視される事になりますが、その一方で何処の誰かが全く同じ名前で別物の私的チャンクを定義する可能性もある事は忘れてはいけません。
PNG画像における画像データの作り方。
PNG画像において、IDATチャンクに納められる画像データは、以下に述べるデータをGZIP形式のデフレート圧縮で圧縮したものです。
横方向ラインのデータ構成。
横方向ラインの画像データは以下のようになります。
- フィルタ種別( 1オクテット)
- 効率良く圧縮を行うために、ライン毎にフィルタの形式を指定する事が出来ます。
フィルタとはデータを圧縮し易くするためにデータの並びを所定の計算式によって揃えて行くものです。
フィルタは可逆的な処理で、実際に画像を表示させる際には各ライン毎にフィルタ種別のデータを見て適切な復元を行います。
- ピクセルデータ
- 1ピクセルがオクテットに満たない場合は左から上位ビット列になるように押込み、一番右端を処理した後の余りビット列は下位の側に残されます。
- フルカラーの場合は、R成分,G成分,B成分の順でデータが並びます。 8ビット型のフルカラーの場合はR成分オクテット, G成分オクテット, B成分オクテットの順に並びます。
- アルファチャネルを用いる場合は、各ピクセルデータの後に当該ピクセルのアルファチャネル値を収めたのデータが続きます(データのオクテット数は型に従います。つまり、 8ビット型なら 1オクテット、16ビット型なら 2オクテットとなります)。勿論、このアルファチャネル値もフィルタの対象となります。
PNG画像でのフィルタについて。
PNG画像でのフィルタとは。
PNG画像では、圧縮効率を高めるため、フィルタと呼ばれる事前データ処理が行われます。
エンコーダは圧縮する前に適切なフィルタを選択して処理します。
また、デコーダは展開した後のデータをフィルタの決まりに従って復元します。
フィルタは、画像の各ライン毎に五種類のアルゴリズムの中から一つを撰ぶ事になっております。
具体的には、エンコーダは各オクテットに対してフィルタ方式で指定された値との差分をフィルタ処理後の値として利用します。
デコーダは展開後にフィルタ方式で指定された値を各オクテットに加える事で元通りの値に戻ると言う訳です。
- フィルタはオクテット単位で処理されます。従ってインデックスドカラーなどのように 1オクテットに複数のピクセルのデータが入る場合は複数ピクセルが纏めてフィルタ処理される事になります。また、フルカラーでは複数オクテットで 1ピクセルのデータを表すため、各オクテットごとにフィルタ処理がされる事となります。
- フルカラーの場合、R(赤成分), G(緑成分), B(青成分)及びA(アルファチャネル)ごとにフィルタ処理が掛けられます。例えば左隣のピクセルとの差分を取る場合、R(赤成分)は左隣のR(赤成分)との差分が取られると言う事になります。
- 無処理フィルタ(フィルタ番号 0)
- データ処理は一切行いません。
フィルタをかけないと言えばよい
と思われるかも知れませんが、PNG画像ではフィルタをかけない事(フィルタ番号のオクテットを附加しない事)は許されておらず、よって無処理のフィルタをかけるというのが正しい言い方と言えます。
- 差分フィルタ(フィルタ番号 1)
- 左隣のピクセル値との差分を取ります。
- 但し、左端のピクセルに対しては差分処理が行われません。
- 上フィルタ(フィルタ番号 2)
- 真上のピクセル値との差分を取ります。
- 但し、真上のピクセルに対しては差分処理が行われません。
- 平均フィルタ(フィルタ番号 3)
- 左隣のピクセル値と真上のピクセル値を足して 2で割った値との差分を取ります。
- 端数は切捨てになります。
- 左端のピクセルの場合、真上のピクセル値を 2で割った値との差分になります。
- 真上のピクセルの場合、左隣のピクセル値を 2で割った値との差分になります。
- ピースのフィルタ(フィルタ番号 4)
- 左隣, 真上及び左上のピクセル値のうち、最も対象となるピクセル値に近いものとの差分を取ります。
- 左端や真上で該当するピクセルが無い場合は、その値は 0と見做して比較します。
- 尚、
ピース
とはこの方式を考案した人の名前です。
PNG画像での最適なフィルタの撰び方。
PNG画像を作成する際にフィルタを選択する場合、五種類もあるフィルタアルゴリズムから、最適なものを一行ごとに選択しなければなりません。
- 但し、実際には真上の場合には上フィルタは意味が無く、よって真上のラインに対しての選択時には除外されて良い事になります。
このため、フィルタを常に 0番(無処理フィルタ)にしているソフトウェアも少なくありません。
また、インデックスドカラーや 8ビット未満のグレイスケールの場合はフィルタの効果は殆ど無い事が知られており、従って
- インデックスドカラーや８ビット未満のグレイスケールでは常にフィルタは 0番(無処理フィルタ)に固定しておき、
- 8ビット以上のグレイスケールやフルカラーでのみ適切なフィルタを撰ぶ
と言うようにすれば良いでしょう。
- 尚、単一のフィルタしか用意出来ない場合は、
フルカラー画像には常にピースのフィルタを適用するようにすると良い
との事です。
実際問題として、各フィルタアルゴリズムを適用して圧縮して最も効果的なものを撰ぶ…という手法は非現実的です。
このため、PNGの仕様書ではエンコーダを作る際の指針として、以下のような最適なフィルタの見積もり方を提案しております。
- 各アルゴリズムに従ってフィルタを掛け、結果となるピクセル値の合計が最も小さくなるものを撰ぶ。
この方法は、基幹技術であるデフレート圧縮(LZ77圧縮)に見られる、「価のバラつきは小さい方が圧縮し易い」という性質に基いたものと思われます。
価の合計値が小さくなれば、それだけ各ピクセルの価のバラつきが小さくなって圧縮し易くなると言う訳です。
この方法は制作者も実際に試してみましたが、概ね良好な結果となりました。
勿論、更に研究が進めばもっと適切な見積もり方も見付かるかも知れません
が、現状ではこれでも充分と言えると思われます。
- 実際問題として、フルカラー画像の場合、適切なフィルタを掛ける事でファイルサイズを最低でも一割くらいは削減出来るようです。
追記(平成16年 9月22日)。
実験を重ねた結果、フルカラーでのフィルタは常に「ピースのフィルタ」に固定しておいた方が、下手にフィルタを撰ぶより効率がよい事が判明しました。
- 勿論、画像のタイプにも依るのですが、JPEG形式で効率良く圧縮出来るような画像ではピースのフィルタが一番効率が良いようです。
インタレースPNG画像について。(平成17年 7月26日)
PNG画像では、GIF画像同様インタレース方式をサポートしております。
インタレースPNG画像では、プログレッシヴな表示を実現するために、画像を七段階に分けて処理します。
- この方法は考案者の名前を取ってアダム 7方式と言います。
具体的には、画像を 8ピクセルズ四方のブロックに分割して、各ブロックから段階ごとに指定されたピクセルを抽出したものを縦横に再配列したものに対して各行ごとに適切なフィルタを掛けてピクセル列にします。
ブロック内のピクセルと段階の関係は以下の通りです。
| X座標 | |||||||||
|---|---|---|---|---|---|---|---|---|---|
| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | ||
| Y座標 | 0 | 1 | 6 | 4 | 6 | 2 | 6 | 4 | 6 |
| 1 | 7 | 7 | 7 | 7 | 7 | 7 | 7 | 7 | |
| 2 | 5 | 6 | 5 | 6 | 5 | 6 | 5 | 6 | |
| 3 | 7 | 7 | 7 | 7 | 7 | 7 | 7 | 7 | |
| 4 | 3 | 6 | 4 | 6 | 3 | 6 | 4 | 6 | |
| 5 | 7 | 7 | 7 | 7 | 7 | 7 | 7 | 7 | |
| 6 | 5 | 6 | 5 | 6 | 5 | 6 | 5 | 6 | |
| 7 | 7 | 7 | 7 | 7 | 7 | 7 | 7 | 7 | |
ところで、画像の幅または高さが 4ピクセルズ以下の場合、対応するピクセルの無い段階が生じ得ます。
この場合、当該段階はピクセルが無い以上フィルタを掛ける意味もありません。
よって、当該段階にはフィルタは掛けられず、ピクセル列も一切存在しないものとなります。
- 例えば、幅 4ピクセルズ、高さ 8ピクセルズの画像は以下のようになります。
- 第一パス：フィルタデータと 1ピクセル分のデータ
- 第二パス：該当するピクセルが無いので、データは空となります
- 第三パス：フィルタデータと存在する 1ピクセル分のデータ
- 以下略
インタレースPNGでは縦横を満遍無く展開して行くため、途中でも画像の内容が分かり易いのが特徴です。
- インタレースGIF画像の場合は行単位で処理されるため、バーコード状に表示されて行き、ちょっと細かい情報が分かり難いと言うデメリットがあります。
しかしながら、インタレースPNG画像は、インタレースGIF画像に比べるとかなり複雑な処理になります。
特に各段階ごとに抽出したデータを処理するため、インタレースGIF画像に較べてどうしてもファイルサイズが大きくなってしまうという欠点があります。
このため、インタレースPNG画像は余り用いられる事は無いようです。
- 一部のブラウザはインタレースPNGは初めの数段階を纏めて表示させるものがあるようです。これは恐らくブラウザのクライアント領域の再描写が負荷になると判断したのでしょう。
参考事項・MNG動画について。(平成16年 9月22日)
MNG動画は「マルティプルイメージ・ネットワーク・グラフィックス」の略で、PNG画像を拡張した動画形式として、西暦2000年(平成12年)に策定されました(勧告は西暦2001年 1月)。
PNG画像の普及が遅れた最大の理由として、GIF画像がサポートしていた簡易動画機能(アニメーション)をサポートしなかった事が挙げられました。
PNG画像はあくまでも画像の規格なので簡易なものであろうと動画機能は不要だと判断した事が仇になったのです。
このため、PNG画像を拡張した動画形式の策定が行われ、生まれたのがMNG動画と言う訳です。
MNG動画の特徴は以下の通りです。
- PNG画像の仕様を拡張したものなので、PNG画像のアニメーションとなる。
- シグネーチャとチャンクと言う構成はPNG画像と全く同じです。
シグネーチャはPNG画像と区別するために新しいものが制定され、動画を実現する為に新たなチャンクが追加定義されました。
実際にはMNG動画形式としては単一の静止画PNG画像も認められます。つまり、MNG動画はPNG画像と完全に上位互換性があります。
- PNG画像だけでなくJPEG画像を組込む事も出来る。
- 但し、JPEG画像を組込むには予めJNG(ジング)画像と呼ばれる形式に変換する必要があります。
JNG画像は「JPEG・ネットワーク・グラフィックス」の略で、MNG動画にJPEG画像を組込めるようにするため、PNG画像/MNG動画のチャンク仕様に合わせた画像形式です。従来のJPEG画像に加えてアルファチャネルを別チャンクで組込む事も出来ます。
- 同じPNG/JNG画像を何度でも繰返し利用出来る。
- アニメーションGIFの場合、同じ画像でも出て来る度に挿入しなければなりません。
MNG動画では、始めに利用する画像に番号を付けて登録し、「何番の画像をどう表示させるか」というデータを並べて動画を実現します。
このため、同じ画像を使い廻す場合はアニメーションGIFより小さくなります。
- より本格的な動画機能を有している。
- アニメーションGIFのような簡易な動画機能ではなく、かなり本格的な機能を有しております。
しかしながら、実装しているブラウザが未だに皆無と言う状況で、もはや完全に死んだ規格となってしまいました。
- もじら(現・もじらシーモンキー)は西暦2003年(平成15年)までサポートしておりましたが、米国でのGIF画像基幹技術の特許権失効を受けてかサポートを打ち切りました。
- 今でも一部の携帯電話でサポートされておりますが、サポートは限定的で、フルサポートとなっている端末は殆どありません。
その理由はいろいろ考えられますが、
- 余りにも煩雑過ぎる
- MNG動画の仕様はとてつもなく複雑で、忠実に実装する事は極めて困難です。
- もじらの場合、画像関連のライブラリのちょうど半分がMNGのために用意されたと言う事です。つまり、GIF画像, JPEG画像, ビットマップなどの処理に必要なコード全部とほぼ同じ量のコードが必要だったと言う事です。
この煩雑さ見越してか、一部を省略したMNG-LCや更に縮小したMNG-VLCと言う仕様も併せて用意されたのですが、何処かの画像作成ツールがフル規格を実装してしまうと当然ユーザエージェント側も対応せざるを得なくなります。拡張子もMIMEタイプでもサブセットとフル規格の区別は出来ず、結局フル規格を実装しないと対応出来ない恐れが出てきます。
- 実は中途半端な仕様だった
- 本格的な動画を標榜するくせに音声の扱い方は全く仕様に組まれておりません。
簡単なパタパタアニメならともかく、本格的な動画と言うのであればまさに看板に偽りありの羊頭狗肉です。
- 既に割込む余地が無かった
- 一口に動画と言っても、そのレヴェルはさまざまです。
- 簡単なパタパタアニメならアニメーションGIFで充分です。
- 実はPNG画像にもアニメーションGIFと同レヴェルの単純な動画機構を組込む事を提案した人もいますし、現在もそう言う仕様が提唱されております。しかし、本格的な動画をと言う事で尽く却下されてしまったのです。
- アニメーションGIFでは無理でもMNG動画でやれる事はフラッシュで全部出来ます。
しかも、フラッシュプレーヤの普及率はPC向けのブラウザなら98％以上にもなっております。
更にフラッシュなら音声を加えるなどMNG動画で出来ない事も出来ます。
- 更により本格的な動画になら、圧縮効率のよいMPEG動画やWMV動画があり、MNG動画では無理です。
- 尚、MNG動画はMPEG動画と共存すると言うスタンスでしたが、効率の悪い可逆圧縮では同列に位置する事自体無理だったのかも知れません(MPEG動画は不可逆圧縮)。
こう考えるともはやMNG動画が押し退けるには余りに遅過ぎたと思われます。
- 簡単なパタパタアニメならアニメーションGIFで充分です。
参考事項・アニメーションPNG画像(APNG画像)について。(平成19年 4月24日)
APNG・アニメーションPNG画像は、PNG画像を拡張してアニメーションを実現すると言うものです。
西暦2003年(平成15年) 6月に唯一MNG動画を実装していたもじら(現・シーモンキー)がサポートを打ち切ってしまい、その後もじら開発スタッフが代わりのものとして提案したものがAPNGでした。
- MNG動画対応打ち切りの背景には米国でのGIF画像基幹技術・LZW圧縮アルゴリズムの特許失効などがあったと思われます。
APNGはしばらく立ち消えとなりましたが、西暦2006年(平成18年)に再度APNGに関する開発が行われるようになりました。
しかし、PNG画像形式ワーキングティーム(W3Cなどとは直接の繋がりは無い)はPNG画像をあくまでも静止画の規格、すなわち単一の画像データのみを扱う規格とする事に固執しており、代わりに一連の画像を一枚に纏めてそこから一コマ一コマを切り出して代りばんこに表示させるモンタージュPNGや、アニメーションGIF画像にPNG形式のデータを収めた規格を提案しているようです。
- モンタージュPNGもアニメーションGIF画像にPNG形式のデータを埋め込む規格も後方互換性を全く考えておりません。モンタージュPNGは対応していない環境でも表示は出来ますが、全てのコマが並んで表示されてしまいます。また、全部の画像を一度に扱わなければならないためメモリを過剰に消費してしまい、余りに非現実的です。
- このあたりの詳細はAPNGメモが詳しいでしょう。
APNGは、従来のPNG画像対応環境でも取扱え(この場合は静止画になる)、且つAPNG対応環境ではアニメーションとして表示されるようになっております。
APNGの具体的な構造は以下のようになります。
- シグネーチャ, IHDRチャンク, PLTEチャンク, tRNSチャンク, IENDチャンクは従来通り。
- 従来のPNG画像対応環境のためにIDATチャンクに依る静止画像が用意される。この画像はアニメーションの第零コマ目か、アニメーションとは全く別のものとする。
- アニメーションPNGである事を示し、且つコマ数と繰り返し回数を指定するacTLチャンクをIDATチャンクの前におく。
- 各コマはコマの表示位置などを指定するfcTLチャンクと、それに続く圧縮画像のチャンクの組となる。
圧縮画像のチャンクは、
- 第零コマ目を従来のPNG画像対応環境向けの代替静止画とする場合にはIDATチャンク
- その他の場合にはfdATチャンク
で表される。
尚、fdATチャンクの形式はIDATチャンクとチャンク名以外は全く同様で、エンコーダの都合で複数チャンクとなっても良い。
- 第零コマ目を従来のPNG画像対応環境向け代替静止画としない場合には、IDATチャンクは第零コマ目のfcTLチャンクの前に置かれる。
- アニメーションGIFで利用出来た各コマでの個別パレットは使えない。インデックスドカラー, グレイスケール及びトゥルーカラーの中から二つ以上を混在させる事も出来ない。
この仕様に依り、
- 従来のPNGデコーダはアニメーションのために導入されたacTLチャンク, fcTLチャンク及びfdATチャンクを読み飛ばして通常のPNG画像同様IDATチャンクをそのまま扱い、
- APNG対応デコーダならacTLチャンク, fcTLチャンク及びfdATチャンクを認識してアニメーションを実現するようになる
と言う訳です。
実際問題として、この規格はMNG動画とは較べ物にならないほど単純で、且つかつての目論見だったGIF画像を置き換えるために欠かせない規格と言えます。
とは言うものの、PNG画像形式ワーキングティームがこの規格について否定的な態度を取っている事から、仕様として定めたところで普及するかどうかは分かりません。
- 上述の通り、現在のPNG画像形式ワーキングティームはW3Cなどとは直接のつながりはありません。このため政治的にAPNGを潰す事は無理でしょうが、PNG信者にとってワーキングティームのカリスマ性は今も高いようで、彼らが認めていないと言う事でAPNGを否認する者が増える恐れがあります(実際、GIMPの制作ティームはMNG動画を支持しており、一方でAPNGについては正面切って否認しているそうです)。
- 尚、APNGは現在開発中のファイヤーフォックス 3.xにて実装される予定ですが、オペラも9.5以降から実装する事となり、一般向けのAPNG対応ブラウザリリースはオペラの方が先になるでしょう。また、現在もじらとオペラはアップルと共同でWHATWGと言う第二のウェブ標準化団体を立ち上げており、この関係でサファリにもAPNGが実装されるのはそう遠くない事かも知れません。