(転送)PNGファイル構造(PNG画像形式)詳細
Png File Structure Detailed
PNGファイル構造分析(上:PNGファイルの保存形式を理解する)
序文
J2MEモバイルアプリ開発を使用する場合、画像の使用にPNG形式の画像を使用できることを知っています(一部の携帯電話でも、PNG形式の画像のみを使用できます)が、画像を使用すると多くのハイライトが追加される可能性がありますただし、アプリケーションでは、PNG形式のみがサポートされています。この図は、さらなる開発の可能性を制限しています(実際、モバイルプラットフォームでの処理能力は制限されていると言わなければなりません)。 MIDP2、または一部のベンダー(NOKIAなど)では、drawPixels / getPixelsのメソッドを提供するAPIを提供しています。これにより、開発者の処理がさらに向上します。画像の柔軟性ですが、現在、MIDP2はまだ十分に普及していないため、このメソッドをで実装する必要があります。 MIDP1 .0も気まぐれであるため、より高度なアプリケーションを実現するには、PNGの可能性を十分に活用する必要があります。
PNGファイル構造
PNGファイルの場合、そのファイルヘッダーは常に固定バイト数で記述されます。
10進数 | 137 80 78 71 13 10 26 10 |
16進数 | 89 50 4E 47 0D 0A 1A 0A |
最初のバイト0x89はASCII文字の範囲外です。これは、一部のソフトウェアがPNGファイルをテキストファイルとして処理するのを防ぐためです。ファイルの残りの部分は、特定の順序で3つ以上のPNGチャンクで構成されています。したがって、標準のPNGファイル構造は次のようになります。
PNGファイルのロゴ | PNGデータブロック | …… | PNGデータブロック |
PNGデータブロック(チャンク)
PNGは、2種類のデータブロックを定義します。1つは標準データブロックであるクリティカルデータブロック(クリティカルチャンク)と呼ばれ、もう1つはオプションのデータブロックである補助データブロック(補助チャンク)と呼ばれます。キーデータブロックは4つの標準データブロックを定義し、それぞれがPNGファイルに含まれている必要があり、PNG読み取り/書き込みソフトウェアもこれらのデータブロックをサポートしている必要があります。 PNGファイル仕様では、オプションのデータブロックをエンコードおよびデコードするためにPNGコーデックは必要ありませんが、仕様ではオプションのデータブロックのサポートが推奨されています。
次の表は、PNGのデータブロックのカテゴリを示しています。ここでは、暗い背景を使用して主要なデータブロックを区別しています。
PNGファイル形式のデータブロック | ||||
データブロックシンボル | ブロック名 | 複数のデータブロック | オプション | 場所の制限 |
IHDR | ファイルヘッダーブロック | しない | しない | 最初の作品 |
cHRM | ベースカラーとホワイトポイントのデータブロック | しない | はい | PLTEおよびIDATの前 |
スペクトラム | 画像ガンマブロック | しない | はい | PLTEおよびIDATの前 |
sBIT | 有効なビットデータブロックのサンプル | しない | はい | PLTEおよびIDATの前 |
PLTE | パレットデータブロック | しない | はい | IDATの前 |
bKGD | 背景色データブロック | しない | はい | PLTE後のIDT前 |
hIST | 画像ヒストグラムブロック | しない | はい | PLTE後のIDT前 |
tRNS | 画像透過データブロック | しない | はい | PLTE後のIDT前 |
oFF | (専用公開データブロック) | しない | はい | IDATの前 |
pHY | 物理ピクセルサイズデータブロック | しない | はい | IDATの前 |
sCAL | (専用公開データブロック) | しない | はい | IDATの前 |
IDAT | 画像データブロック | はい | しない | 他のIDATと継続 |
時間 | 画像の最終変更時間ブロック | しない | はい | 無制限 |
テキスト | テキスト情報データブロック | はい | はい | 無制限 |
zTXt | 圧縮されたテキストブロック | はい | はい | 無制限 |
尾 | (専用公開データブロック) | はい | はい | 無制限 |
gIFg | (専用公開データブロック) | はい | はい | 無制限 |
贈り物 | (専用公開データブロック) | はい | はい | 無制限 |
gIFx | (専用公開データブロック) | はい | はい | 無制限 |
IEND | 画像終了データ | しない | しない | 最後のデータブロック |
簡単にするために、使用するPNGファイルでは、4つのデータブロックが上記の順序で格納され、1回だけ表示されると想定しています。
データブロック構造
PNGファイルでは、各データブロックは次の4つの部分で構成されます。
名前 | バイト数 | 説明 |
長さ | 4バイト | データブロック内のデータフィールドの長さを指定します。長さは(231-1)バイト |
チャンクタイプコード | 4バイト | ブロックタイプコードはASCII文字(A-Zおよびa-z)で構成されます |
チャンクデータ(データブロックデータ) | 可変長 | チャンクタイプコードで指定されたデータを保存する |
CRC(巡回冗長検査) | 4バイト | エラーを検出するために巡回冗長コードを保存する |
CRC(巡回冗長検査)フィールドの値は、チャンクタイプコードフィールドとチャンクデータフィールドのデータから計算されます。 CRC固有のアルゴリズムはISO3309およびITU-TV.42で定義されており、その値は次のCRCコード生成多項式によって計算されます。
バツ32+ x26+ x2. 3+ x22+ x16+ x12+ x十一+ x10+ x8+ x7+ x5+ x4+ x二+ x + 1
以下では、各キーデータブロックの構造を見てみましょう。
IHDR
IHDR(ヘッダーチャンク):PNGファイルに保存されている画像データの基本情報が含まれ、PNGデータストリームの最初のデータブロックとして表示されます。PNGデータストリームには1つのファイルしか存在できません。ヘッドデータブロック。
ヘッダーデータブロックは13バイトで構成され、その形式を次の表に示します。
ドメインの名前 | バイト数 | 説明 |
幅 | 4バイト | ピクセル単位の画像幅 |
高さ | 4バイト | 画像の高さ(ピクセル単位) |
ビット深度 | 1バイト | 画像の深さ: インデックスカラー画像:1、2、4または8 グレースケール画像:1、2、4、8または16 トゥルーカラー画像:8または16 |
ColorType | 1バイト | 色の種類: 0:グレースケール画像、1、2、4、8または16 2:トゥルーカラー画像、8または16 3:インデックスカラー画像、1、2、4または8 4:アルファチャネルデータを含むグレースケール画像、8または16 6:アルファチャネルデータを含むトゥルーカラー画像、8または16 |
圧縮方法 | 1バイト | 圧縮方法(LZ77派生アルゴリズム) |
フィルター法 | 1バイト | フィルター法 |
インターレース方式 | 1バイト | インターレース方式: 0:ノンインターレーススキャン 1:Adam7(Adam M. Costelloによって開発された7パスインターレース方式) |
携帯電話でPNGを調査しているので、最初に、使用するPNG画像に対するMIDP1.0の要件を見てみましょう。
- MIDP 1.0では、バージョン1.0のPNG画像のみを使用できます。したがって、PNGキーデータブロックには特別な要件があります。
IHDR - ファイルサイズ:MIDPは任意のサイズのPNG画像をサポートします。ただし、実際には、画像が大きすぎると、メモリが枯渇するために読み取れなくなります。
- 色の種類:すべての色の種類がサポートされていますが、これらの色の表示は実際のデバイスの表示機能によって異なります。同時に、MIDPはアルファチャネルもサポートできますが、すべてのアルファチャネル情報は無視され、不透明な色として扱われます。
- 色深度:すべての色深度をサポートできます。
- 圧縮方法:jarファイルの圧縮とまったく同じ圧縮モード0(デフレート圧縮モード)のみをサポートします。したがって、PNG画像データの解凍とjarファイルの解凍は同じコードを使用できます。 (実際、これがJ2MEがPNG画像を非常にうまくサポートできる理由です:))
- フィルタ方法:PNGホワイトペーパーでは方法0のみが定義されていますが、5つの方法すべてがサポートされています。
- インターレーススキャン:MIDPは0と1の両方をサポートしますが、インターレーススキャンを使用する場合、MIDPは実際にはインターレーススキャンを使用しません。
- PLTEチャンク:サポート
- IDATチャンク:画像情報は、5つのフィルタリング方法(なし、サブ、アップ、平均、ペート)のモード5を使用する必要があります
- IENDチャンク:このPNG画像は、IENDデータブロックが見つかったときに正当なPNG画像と見なされます。
- オプションのデータブロック:MIDPは次の補助データブロックをサポートできますが、これは必須ではありません。
bKGD cHRM gAMA hIST iCCP iTXt pHY
sBIT sPLT sRGB tEXt tIME tRNS zTXt
詳細については、を参照してください。 http://www.w3.org/TR/REC-png.html
PLTE
パレットブロックPLTE(パレットチャンク)には、インデックスカラー画像にのみ関連するインデックスカラー画像に関連付けられた色変換データが含まれ、画像データチャンクの前に配置されます。
PLTEデータブロックは、画像を定義するパレット情報です。 PLTEには1〜256のパレット情報を含めることができ、各パレット情報は3バイトで構成されます。
色 | バイト | 意義 |
ネット | 1バイト | 0 =黒、255 =赤 |
緑 | 1バイト | 0 =黒、255 =緑 |
青い | 1バイト | 0 =黒、255 =青 |
したがって、パレットの長さは3の倍数にする必要があります。そうしないと、不正なパレットになります。
インデックス画像の場合、パレット情報が必要です。パレットのカラーインデックスには0、1、2 ...の順に番号が付けられ、パレットの色数は、色深度で指定された色数(画像の色など)を超えることはできません。深さが4の場合、パレットの色数は2 ^ 4 = 16を超えることはできません。そうしないと、PNG画像が不正になります。
アルファチャネルデータを備えたトゥルーカラー画像およびトゥルーカラー画像はまた、非トゥルーカラー表示プログラムが画像データを量子化して画像を表示することを容易にする目的でパレットデータブロックを有することができる。
IDAT
画像データチャンクIDAT(画像データチャンク):実際のデータを格納し、データストリームに複数の連続した連続画像データチャンクを含めることができます。
IDATは画像の実際のデータ情報を格納しているので、IDATの構造を理解できれば、PNG画像を簡単に生成できます。
IEND
IEND(画像トレーラーチャンク):PNGファイルをマークするために使用されるか、データストリームが終了したため、ファイルの最後に配置する必要があります。
PNGファイルをよく見ると、ファイルの最後にある12文字は常に次のようになっているはずです。
00 00 00 00 49 45 4E 44 AE 42 60 82
データブロック構造の定義により、IENDデータブロックの長さは常に0(情報が人為的に追加されない限り、00 00 00 00)であり、データ識別子は常にIEND(49 45)であることを理解するのは難しくありません。したがって、CRCコードは常にAE 42 6082です。
ケーススタディPNG
以下は、Fireworksによって生成された画像サイズ8 * 8の画像です。 誰もが見やすいように、画像を拡大します。
次のようにUltraEdit32でファイルを開きます。
00000000〜00000007:
選択された最初の8バイトがPNGファイルの識別子であることがわかります。
次の場所はIHDRデータブロックです。
00000008〜00000020:
- 00 00 000D説明IHDRヘッダーブロック長は13です
- 49 48 44 52IHDRロゴ
- 00 00 00 08画像の幅、8ピクセル
- 00 00 00 08画像の高さ、8ピクセル
- 04色深度、2 ^ 4 = 16、つまり、これは16色の画像です(もちろん、色数が8を超えない場合は、色数が16を超えない可能性もあります。 03)を使用するのがより適切です
- 03カラータイプ、インデックス画像
- 00 PNG仕様は、ここが常に0であることを指定しています(ゼロ以外の値は、将来のより良い圧縮方法のために予約されています)、圧縮方法(LZ77派生アルゴリズム)を示します
- 00上記と同じ
- 00非インターレーススキャン
- 36 21 A3 B8CRCチェック
00000021〜0000002F:
オプションのデータブロックsBIT、カラーサンプリングレート、RGBは256(2 ^ 8 = 256)
00000030〜00000062:
これがパレット情報です
- 00 00 00 27説明パレットデータの長さは39バイトで、13色です。
- 50 4C 54 45PLTEロゴ
- FF FF00カラー0
- FF ED00カラー1
- …………
- 09 00 B2最終色、12
- 5F F5 BB DDCRCチェック
00000063〜000000C5:
この部分には、pHYとtExtの3つのブロックが含まれていますが、これらはあまり詳細ではなく、詳細にも説明されていません。
000000C0〜000000F8:
上で選択した部分はIDATデータブロックです。
- 00 00 0027データ長は39バイトです
- 49 44 41 54IDATロゴ
- 78 9C ...圧縮データ、LZ77派生圧縮方式
- DA 12 06 A5CRCチェック
IDATの圧縮データ部分については、後で詳しく説明します。
000000F9〜00000104:
IENDデータブロック、この部分は、上記のように、通常は
00 00 00 00 49 45 4E 44 AE 42 60 82
この時点で、PNGファイルから個々のデータブロックを特定することができました。 PNGは、重要なデータブロックを除くすべての補助データブロックがオプションであると指定しているため、この標準の後に、すべての補助データブロックを削除することでPNGファイルのサイズを減らすことができます。 (もちろん、PNG形式では画像内のレイヤーやテキストなどの情報を保存できることに注意してください。これらの補助データブロックが削除されると、画像は元の編集機能を失います。)
補助データブロック後のPNGファイルが削除されました。ファイルサイズは147バイトになり、元のファイルサイズは261バイトになりました。ファイルサイズが縮小された後、画像のコンテンツは影響を受けません。
実際、雲/水の波の流れ効果の実装、画像のフェード効果の実現など、パレットの色の値を変更することで、いくつかの興味深いことができます。ここに、誰もが見ることができるリンクを示します。多分もっと直接的に: http://blog.csdn.net/flyingghost/archive/2005/01/13/251110.aspx 、私はこの記事を書いたこの記事に触発されています。
で述べたように、IDATデータブロックはLZ77圧縮アルゴリズムを使用して生成されます。モバイルプロセッサの機能が制限されているため、IDATデータブロックを生成する場合は引き続きLZ77を使用します。圧縮アルゴリズムは、効率を大幅に低下させます。したがって、効率を上げるために、非圧縮のLZ77アルゴリズムのみを使用でき、LZ77アルゴリズムの特定の実装が実装されます。この記事は研究を目的としたものではありません。 LZ77アルゴリズムのJAVA実装に興味がある場合は、次の2つのサイトを参照できます。
参考資料:
PNGファイル形式のホワイトペーパー: http://www.w3.org/TR/REC-png.html
は、数少ない中国語のPNG形式の説明の1つです。 http://dev.gameres.com/Program/Visual/Other/PNGFormat.htm
RFC-1950(ZLIB圧縮データ形式仕様): ftp://ds.internic.net/rfc/rfc1950.txt
RFC-1950(DEFLATE圧縮データ形式仕様): ftp://ds.internic.net/rfc/rfc1951.txt
LZ77アルゴリズムのJAVA実装: http://jazzlib.sourceforge.net/
J2MEバージョンを含むLZ77アルゴリズムのJAVA実装: http://www.jcraft.com/jzlib/index.html
元のアドレス:http://www.ismyway.com/png/png-struct1.htm