この章では標準型の PNG チャンクについて説明します。
すべてのアプリケーションは標準的な必須チャンクを解釈しなければなりません。正当な PNG イメージはひとつの IHDR チャンク、ひとつ以上の IDAT チャンク、ひとつの IEND チャンクを含む必要があります。
IHDR チャンクは最初に現れる必要があり、以下のものを格納します：
幅: 4 bytes 高さ: 4 bytes ビット深度： 1 byte カラータイプ： 1 byte 圧縮手法： 1 byte フィルター手法： 1 byte インターレース手法：1 byte
幅と高さはイメージの寸法をピクセル単位で示します。それらは 4-byte の整数です。0 は無効な値です。それぞれの最大値は 4-byte の無符号値を扱うのが困難な言語に適応するため
ビット深度はサンプルあたりもしくはパレットインデックスあたりのビット数（ピクセルあたりではありません）を示す 1-byte の整数です。有効な値は 1, 2, 4, 8, 16 ですが、すべてのカラータイプに対してすべての値が許されるものではありません。
カラータイプはイメージデータの解釈を表す 1-byte の整数です。カラータイプコードは以下の値の合計で表現されます。1:パレット使用、2:カラー、4:αチャンネル。有効な値は 0, 2, 3, 4, 6 です。
アプリケーションの簡略化と良好な圧縮が得られない組み合わせを予防するために、それぞれのカラータイプに対してビット深度の制限があります。デコーダはすべての有効なビット深度とカラータイプの組み合わせをサポートする必要があります。許される組み合わせは以下の通りです：
カラー 許される 解釈
タイプ ビット深度
0 1,2,4,8,16 それぞれのピクセルがグレースケールサンプル。
2 8,16 それぞれのピクセルが R, G, B 。
3 1,2,4,8 それぞれのピクセルがパレットインデックスであり、
PLTE チャンクが現れる必要があります。
4 8,16 それぞれのピクセルがグレイスケールサンプルと、
それに続くαサンプル。
6 8,16 それぞれのピクセルが R, G, B
それに続くαサンプル。
サンプル深度が常に 8-bit であるカラータイプが 3 の場合を除いてサンプル深度はビット深度と同じです。
圧縮手法はイメージデータを圧縮するのに用いられる手法を示す 1-byte の整数です。現在、圧縮手法 0 （最大 32768-byte スライドの deflate/inflate 圧縮）のみが定義されています。すべての標準的な PNG イメージはこの枠組みで圧縮される必要があります。圧縮手法フィールドは将来の拡張や独自の変種の可能性に備えるものです。デコーダはこのバイトをチェックしもし認識できないコードだった場合にエラーを報告する必要があります。詳細は Deflate/Inflate Compression を参照してください。
フィルター手法は圧縮前のイメージデータに対して適用される前処理の手法を示す 1-byte の整数です。現在、フィルター手法 0 （5 つの基本フィルターによる順応フィルタリング）のみが定義されています。圧縮手法フィールドと同様に、デコーダはこのバイトをチェックしもし認識できないコードだった場合にエラーを報告する必要があります。詳細は Filter Algorithms を参照してください。
インターレース手法はイメージデータの転送序列を示す 1-byte の整数です。現在、0 （非インターレース）と 1 （Adam7 インターレース）のふたつの値が定義されています。詳細は Interlaced data order を参照してください。
PLTE チャンクは以下のような 3-byte が連続する 1 から 256 までのパレットエントリを格納します：
Red: 1 byte (0 = black, 255 = red) Green: 1 byte (0 = black, 255 = green) Blue: 1 byte (0 = black, 255 = blue)
エントリ数はチャンク長から決定されます。チャンク長が 3 で割り切れないときはエラーとなります。
このチャンクはカラータイプが 3 のとき現れる必要があり、カラータイプが 2, 6 のとき現れる可能性があります。カラータイプが 0, 4 のｔき現れてはいけません。このチャンクが現れるときは、最初の IDAT チャンクに選考する必要があります。ひとつより多くの PLTE チャンクは存在してはいけません。
カラータイプ 3 （インデックスカラー）の場合、PLTE が必要です。PLTE の最初のエントリはピクセル値 0 によって、２番目はピクセル値 1 によって...参照されます。パレットエントリ数はイメージのビット深度によって示すことのできる範囲を超えてはいけません（たとえば、ビット深度 4 のとき、24 = 16 ）。ビット深度が認めるエントリよりも少ないことは許されます。その場合、イメージデータ中の範囲外のピクセル値はエラーです。
カラータイプ 2, 6 （トゥルーカラーとα付きトゥルーカラー）の場合、PLTE チャンクは任意です。存在する場合は、ビュアーが直接トゥルーカラーを表示できない場合にトゥルーカラーイメージを減色することのできる 1 から 256 色の推奨セットを提供します。PLTE も sPLT も存在しないとき、そのようなビュアーは自分自身で色を選択する必要がありますが、そのほうがエンコーダによってされてしまうより好ましいこともあります。（エンコーダに対する勧告：Suggested palettes を参照してください）
パレットはイメージのビット深度定義に関わらず、サンプルあたり 8-bit (1-byte) であることに注意してください。とくに、16-bit のトゥルーカラーイメージの推奨減色であってもパレットは 8-bit 深度です。
パレットエントリがすべてイメージによって使われたり、すべてが異なっている必要はありません。
IDAT チャンクは実際のイメージデータを格納します。このデータを生成するためには：
まず、イメージのスキャンラインを Image layout の記述の通りに表現します。生のデータのレイアウトと合計サイズは IHDR のフィールドによって決定できます。
イメージデータを IHDR チャンクのフィルタリング手法の定義にしたがってフィルタリングします。（フィルター手法が現在唯一定義されている 0 だったなら、それぞれのスキャンラインはフィルター形式バイトを持っていることを意味します）
フィルタリングされたデータを IHDR チャンクの圧縮手法定義を使って圧縮します。
IDAT チャンクは圧縮アルゴリズムの出力データストリームを格納します。
イメージデータを読み込むには、このプロセスを逆転します。
IDAT チャンクは複数存在することができます。もしそうなら、それらは、間にほかのチャンクを挟むことなく連続して現れる必要があります。そのとき圧縮されたデータストリームはすべての IDAT チャンクの内容を連結したものです。エンコーダは圧縮されたデータストリームを望みのままに IDAT チャンクに分割する事ができます。（複数の IDAT チャンクは固定されたメモリ量でしか動くことのできないエンコーダのために許されています。通常のチャンクサイズはエンコーダのバッファサイズに一致します）。IDAT チャンクの境界は重要な意味は持ちませんし、圧縮されたデータストリームのどの点にでも現れることができます。それぞれの IDAT チャンクが 1-byte しか格納しないような PNG ファイルも、著しい場所の無駄遣いですが、有効です。（さらに言えば、ゼロ長の IDAT チャンクも、さらに無駄遣いですが、有効です）。
詳細は、 Filter Algorithms と Deflate/Inflate Compression を参照してください。
IEND チャンクは最後に現れる必要があります。これは PNG のデータストリームの終わりを告げます。チャンクのデータ領域は空です。
すべての補助チャンクはエンコーダが書き込む必要がなく、デコーダは無視できるという意味で任意のものす。しかし、エンコーダは情報が利用可能なときは標準的な補助シャンクを書き込むことが推奨され、デコーダは適応でき利用可能なときは、それらのチャンクを解釈することが推奨されます。
標準的な補助チャンクは次の４つの項目で説明されます。これが PNG のデータストリームに現れる順番である必要はありません。
このチャンクは完全なαチャンネルを含まないデータストリームの透明度の情報を伝えます。
tRNS チャンクは、パレットエントリに関連したα値（インデックスカラーイメージ）、もしくは、ひとつの透明色（グレイスケール、トゥルーカラーイメージ）、のどちらかのイメージが使う簡単な透明度を指定します。簡単な透明度は完全なαチャンネルに比べて優雅ではありませんが、より少ない保存場所しか必要とせず、多くの一般的な場合には十分です。
カラータイプが 3 （インデックスカラー）の場合、tRNS チャンクは PLTE チャンクのエントリに一致した 1-byte のα値の連続を格納します：
Alpha for palette index 0: 1 byte Alpha for palette index 1: 1 byte ...etc...
それぞれのエントリはパレットインデックスに一致したピクセルがα値を持っているものとして扱う必要があることを示しています。α値は 8-bit の完全なαチャンネルと同じ解釈を持ちます。イメージのビット深度に関わらず、0 は完全な透明、255 は完全な不透明です。tRNS チャンクはパレットエントリより多くのα値を格納することはできませんが、tRNS パレットエントリよりもすくない値は格納することができます。この場合、残りすべてのパレットエントリのα値は 255 と仮定されます。よくある場合としてパレットインデックス 0 のみを透明にする必要があるときは、tRNS チャンクは 1-byte のみが必要です。
カラータイプが 0 （グレイスケール）の場合、tRNS チャンクは次のような形式でひとつのグレイレベル値を格納します：
Gray: 2 bytes, range 0 .. (2^bitdepth)-1
（イメージのビット深度が 16 より少ないとき、下位ビットが使われほかは 0 です）。指定されたグレイレベルのピクセルは透明として扱い（α値 0 に相当）、ほかのすべてのピクセルは完全な不透明として扱います（α値
カラータイプが 2 （トゥルーカラー）の場合、tRNS チャンクは次のような形式でひとつの RGB カラー値を格納します：
Red: 2 bytes, range0 .. (2^bitdepth)-1Green: 2 bytes, range0 .. (2^bitdepth)-1Blue: 2 bytes, range0 .. (2^bitdepth)-1
（イメージのビット深度が 16 より少ないとき、下位ビットが使われほかは 0 です）。指定されたカラー値のピクセルは透明として扱い（α値 0 に相当）、ほかのすべてのピクセルは完全な不透明として扱います（α値
tRNS はカラータイプ 4, 6 ではすでに完全なαチャンネルがすでに与えられているので禁止されています。
注意：16-bit のグレイスケールやトゥルーカラーのデータを扱う時には、ピクセルが透明であるかどうかを決定するためにサンプル値の両方のバイトを比較することが重要です。たとえ、デコーダが低位バイトを落としてサンプルを表示していたとしても、データの透明度の検証が行われるまでそうしてはいけません。たとえば、グレイスケールレベルが 0x0001 が透明として指定されたとき、間違って高位バイトのみを比較したら 0x0002 も透明と定めてしまいます。
もし tRNS チャンクが存在するなら、最初の IDAT チャンクにの前に置かれ、あるのなら、PLTE チャンクの後ろに置かれる必要があります。
これらのチャンクはイメージサンプルの望ましい表示強度に関係します。
gAMA チャンクはイメージサンプルと望ましい表示出力強度との間の関係をべき関数として規定します。
sample = light_out ^ gamma
ここでは サンプル と 出力を 0.0 から 1.0 の範囲で規格化します：
sample = integer_sample / (2^bitdepth - 1)
gAMA チャンクは次のものを格納します：
Gamma: 4 bytes
値はγ値の 100000 倍相当の 4-byte の無符号整数としてエンコードされます。たとえば、1/2.2 のγ は 45455 として保存されます。
γ値はαサンプルには影響を与えず、常に完全な不透明までの線形です。
エンコーダがイメージのγ値を知らない場合、 gAMA チャンクを書き込むべきではありません。gAMA チャンクが欠落しているということは、γが未知であることを示しています。
技術的には、「望ましい表示出力強度」は指定できず、出力が望ましくなるように閲覧条件を指定する必要があります。gAMA は ISO 標準[ISO-3664]に基づいた sRGB 仕様書[sRGB]の標準閲覧条件に対するものです。異なる閲覧環境の調整は Color Management System (CMS) によって標準的に処理される複雑な手法です。この調整が実行できないとしても、誤差はたいてい小さなものです。アプリケーションが、ハイカラーの忠実さを望むのであれば、sRGB チャンク（ sRGB チャンクの定義を参照してください）や iCCP チャンク（ iCCP チャンクの定義を参照してください）が使えるかもしれません。
gAMA チャンクが現れたときは、最初の IDAT チャンクの前に置かれ、PLTE チャンクが存在するならその前に置かれる必要があります。sRGB チャンクや iCCP チャンクが、存在し認識できるのであれば、gAMA チャンクを無効にします。
Gamma correction、エンコーダの勧告は：Encoder gamma handling、デコーダの勧告は：Decoder gamma handling を参照してください。
アプリケーションがデバイス独立の色定義を PNG ファイルで必要とするなら、イメージ中で基礎的に使われる赤、緑、青の 1931 CIE x,y 色度と基準の白点を指定する cHRM チャンクを使うことができます。さらなる情報は Color Tutorial を参照してください。
cHRM チャンクは以下を格納します。
White Point x: 4 bytes White Point y: 4 bytes Red x: 4 bytes Red y: 4 bytes Green x: 4 bytes Green y: 4 bytes Blue x: 4 bytes Blue y: 4 bytes
それぞれの値は x や y の値を 100000 倍した 4-byte の無符号整数としてエンコードされます。たとえば、0.3127 の値は 整数 31270 として保存されます。
cHRM はたとえほとんど意味のないグレイスケールのイメージであったとしても、すべての PNG ファイルで認められています。
エンコーダが色度の値を知らないときは、 cHRM チャンクを書き込むべきではありません。cHRM チャンクが存在しないと言うことは、イメージの基礎色はデバイス依存であることを示しています。
cHRM チャンクが現れるときは、最初の IDAT チャンクの前に置かれ、PLTE チャンクが存在するならその前に置かれる必要があります。
sRGB チャンクや iCCP チャンクが、存在し認識できるのであれば、cHRM チャンクを無効にします。
sRGB chunk specification、エンコーダへの勧告は：Encoder color handling、デコーダへの勧告は：Decoder color handlingを参照してください。
sRGB チャンクが存在するとき、イメージサンプルは sRGB カラースペース [sRGB] に従い、International Color Consortium [ICC] によって定義された解釈仕様を使って表示するべきでしょう。
sRGB チャンクは以下のものを格納します。
Rendering intent: 1 byte
解釈に以下の値が定義されています：
0: Perceptual 1: Relative colorimetric 2: Saturation 3: Absolute colorimetric
Perceptual 解釈は写真のような比色分析に正確さに重点を置いた出力装置全般に適応しています。
Relative colorimetric 解釈はロゴのようなカラーアピアランスの一致（出力装置の白点に比例した）に向いています。
Saturation 解釈は図やグラフのような色相や明度の保存に重点を置いたイメージに向いています。
Absolute colorimetric 解釈は試験（異なる出力装置のためのプレビュウイメージ）のような比色の絶対値の保存が必要なイメージに向いています。
sRGB チャンクを書き込むアプリケーションは gAMA チャンク（できることなら cHRM チャンク）も sRGB チャンクを使わないアプリケーションとの互換性のために書き込むべきでしょう。このような状況では、以下の値のみが使われます：
gAMA: Gamma: 45455 cHRM: White Point x: 31270 White Point y: 32900 Red x: 64000 Red y: 33000 Green x: 30000 Green y: 60000 Blue x: 15000 Blue y: 6000
sRGB チャンクが存在するとき、それを認識しカラーマネジメント [ICC] をする能力のあるアプリケーションは gAMA や cHRM チャンクを無視し、代わりに sRGB チャンクを使う必要があります。
sRGB チャンクを認識するけれど、完全なカラーマネジメントをする能力のないアプリケーションも gAMA や cHRM チャンクを無視する必要があります。なぜなら、そのアプリケーションはすでにそのチャンクが格納する値を知っているからです。アプリケーションは従って、gAMA と cHRM の値は gAMA と cHRM チャンクに現れたものに超越して与えられる必要があります。
sRGB チャンクが現れたときは、最初の IDAT チャンクの前に置かれ、PLTE チャンクが存在するならその前に置かれる必要があります。sRGB と iCCP チャンクは両方とも現れるべきではありません。
iCCP チャンクが存在するとき、イメージサンプルは International Color Consortium [ICC] によって定義された埋め込み ICC プロフィールによって表示されるカラースペースに従います。ICC プロフィール のカラースペースはカラーイメージ（PNG のカラータイプが 2, 3, 6 ）のついては RGB カラースペース、グレイスケールイメージ(PNG のカラータイプが 0, 4 )についてはモノクログレイスケールカラースペースである必要があります。
iCCP チャンクは以下のものを格納します。
Profile name: 1-79 bytes (character string) Null separator: 1 byte Compression method: 1 byte Compressed profile: n bytes
形式は zTXt チャンクに似ています。（zTXt chunk specification を参照してください）。プロフィール名はプロフィールを参照するのに便利な名前が可能です。大文字と小文字は区別され、 text チャンクのキーワードと同様の制限が課せられます。表示可能な Latin-1 [ISO/IEC-8859-1] の文字（ 33-126 と 161-255 ）と先頭、末尾を除き連続しない空白のみが格納できます。圧縮手法バイトとして現在定義されている唯一の値は deflate 圧縮による zlib データストリームを意味する 0 です（Deflate/Inflate Compression を参照してください）。チャンクの残りの部分を伸展すると ICC プロフィールが現れます。
iCCP チャンクを書き込むアプリケーションは ICC プロフィールの伝達関数を概算する gAMA と cHRM チャンクも iCCP チャンクを使わないアプリケーションとの互換性のために書き込むべきでしょう。
iCCP チャンクが存在するとき、それを認識しカラーマネジメントを行うことのできるアプリケーションは gAMA と cHRM チャンクを無視するするべきで、代わりに iCCP チャンクを使うべきでしょう。アプリケーションが完全にカラーマネジメントを行う能力がないのなら、gAMA と cHRM チャンクが存在するなるならそれを使うべきでしょう。
ファイルは iCCP のような説明的なものであろうと、 sRGB のような絶対的なものであろうと、最大でひとつの埋め込みプロフィールを格納するべきでしょう。
iCCP チャンクが現れたときは、最初の IDAT チャンクの前に置かれ、PLTE チャンクが存在するならその前に置かれる必要があります。
iTXt、tEXt、zTXt チャンクはイメージに関連したテキスト情報を伝達します。この仕様書ではこれらを一般に "text チャンク" と呼びます。
それぞれの text チャンクはテキスト文字列によって表現される情報の種類を表示するキーワードを最初のフィールドに格納します。以下のキーワードがあらかじめ定義され、適切に使われるべきものです：
Title Short (one line) title or caption for image
Author Name of image's creator
Description Description of image (possibly long)
Copyright Copyright notice
Creation Time Time of original image creation
Software Software used to create the image
Disclaimer Legal disclaimer
Warning Warning of nature of content
Source Device used to create the image
Comment Miscellaneous comment; conversion from
GIF comment
作成時間キーワードについて、RFC 1123 の 5.2.14 節で定義されている日付形式が推奨されますが、[RFC-1123] である必要はありません。デコーダはこのほかのキーワードについても自由な形式のテキストを認めるべきでしょう。
ほかのキーワードがほかの目的のために考案されるかもしれません。一般に関心のあるキーワードは PNG 仕様書の管理者によって登録されることができます。しかし、個人的な登録されていないキーワードを使うことも許されています。（個人的なキーワードは同じキーワードが両立しない目的のために異なる人々で使われないように合理的で自己説明的であるべきでしょう）。
キーワードは 1 文字以上 80 文字未満である必要があります。キーワードはつねに ISO/IEC 8859-1 (Latin-1) 文字集合によって解釈されます [ISO/IEC-8859-1]。それらは表示可能な Latin-1 文字と空白のみを格納する必要があります。十進ならば、32-126 と 161-255 の文字のみが許されます。人間がキーワードを読み間違える可能性を減らすため、先頭と末尾の空白、連続した空白は禁止されています。non-breaking space (code 160) は普通の空白と視覚上見分けがつかないためキーワード中には許されていないことに注意してください。
デコーダは特定のキーワードを探すときに融通の利かない単純な比較を使うことができるので、キーワードは登録されたとおりにつづる必要があります。とくに、キーワードは大文字と小文字の区別を重視します。
text チャンクはいくつでも現れることができ、おなじキーワードが１回以上あることも認められています。
エンコーダの勧告は：Text chunk processing、デコーダの勧告は：Text chunk processing を参照してください。
エンコーダがイメージと一緒に記録しようとするテキスト情報は tEXt チャンクに保存することができます。それぞれの tEXt チャンクはひとつのキーワード（上記参照）とテキスト文字列を次の形式で格納します：
Keyword: 1-79 bytes (character string) Null separator: 1 byte Text: n bytes (character string)
キーワードとテキスト文字列はゼロバイト（NULL 文字）によって区別されます。キーワードもテキスト文字列もどちらも NULL 文字を含めることはできません。テキスト文字列が NULL で終わらないことに注意してください（チャンク長は終了位置の十分な情報です）。テキスト文字列は 0-byte からチャンクサイズが許す最大値からキーワードと分割子を除いたサイズまでのどんな長さも可能です。
テキストは ISO/IEC 8859-1 (Latin-1) [ISO/IEC-8859-1] 文字集合に従って解釈されます。テキスト文字列はどのような Latin-1 も格納できます。テキスト文字列中の改行は LF 文字（十進 10）ひとつで表現されるべきです。ほかのコントロール文字をテキスト中に使うことは推奨されません。
zTXt チャンクは tEXt が行うのと同様のテキストデータを格納しますが、 zTXt は圧縮の利点をとります。zTXt と tEXt チャンクは意味的には等価ですが、zTXt は大きなサイズのテキストを保存するのに推奨されます。
zTXt チャンクは以下のものを格納します：
Keyword: 1-79 bytes (character string) Null separator: 1 byte Compression method: 1 byte Compressed text: n bytes
キーワードと NULL 分割子は tEXt チャンクと全く同じです。キーワードは圧縮されていないことに注意してください。圧縮手法バイトはこの zTXt チャンクの中で使われる圧縮手法を示しています。現在定義さえている唯一の値は 0 （deflate/inflate 圧縮）です。圧縮手法バイトにはチャンクの残りの部分で構成される圧縮されたデータストリームが続きます。圧縮手法が 0 のとき、このデータストリームは zlib データストリームに忠実です（Deflate/Inflate Compression を参照してください）。データストリームを伸展することで tEXt チャンクに保存されているものと等価の Latin-1 のテキストが現れます。
このチャンクは意味的には tEXt と zTXt チャンクと等価ですが、テキストデータが Latin-1 の代わりに UTF-8 でエンコードされた Unicode 文字です。このチャンクは次のものを格納します。
Keyword: 1-79 bytes (character string) Null separator: 1 byte Compression flag: 1 byte Compression method: 1 byte Language tag: 0 or more bytes (character string) Null separator: 1 byte Translated keyword: 0 or more bytes Null separator: 1 byte Text: 0 or more bytes
キーワードは上で説明されています。
圧縮フラグは 0 が無圧縮のテキスト、1 が圧縮されたテキストです。テキスト領域のみが圧縮される可能性があります。現在定義されている唯一の圧縮手法バイトが deflate 圧縮による zlib データストリームを意味する 0 です。圧縮されてないテキストには、エンコーダは圧縮手法に 0 をセットするべきで、デコーダはそれを無視するべきでしょう。
language tag [RFC-1766] は翻訳されたキーワードとテキストがつかっている人間の言語を示しています。キーワードと違い language tag は大文字と小文字を区別しません。それはハイフンで区切られた 1-8 文字からなる ASCII 文字列 [ISO-646] です（たとえば： cn, en-uk, no-box, x-klingon ）。最初の句が 2 文字のとき、それは ISO language code です [ISO-639]。language tag が空のとき、言語は未定義です。
翻訳されたキーワードとテキストは両方とも UTF-8 エンコードされた Unicode 文字集合を使い[ISO/IEC-10646-1]、どちらもゼロバイト（NULL 文字）を含む可能性はありません。テキストはほかの文字列と異なり、NULL 終端がありません。その長さはチャンク長によって暗示されます。
改行は翻訳されたキーワードには現れるべきではありません。テキスト中では改行は LF 文字（十進 10）ひとつで表現されるべきでしょう。残りのコントロール文字（ 1-9, 11-31, 127-159 ）は翻訳されたキーワードとテキストの両方で推奨されません。UTF-8 では、文字の 128-159 （推奨されない） とバイトの 128-159 （ときとして必要） が異なることに注意してください。
翻訳されたキーワードは空でなければ language tag で示された言語にキーワードを翻訳したものを格納するべきで、アプリケーションのキーワードの表示は翻訳されたキーワードを追加的に表示するべきでしょう。
これらのチャンクはイメージに関連したそのほかの情報を伝えるために使われます。
bKGD チャンクはイメージに対して存在するデフォルトの背景色を指定します。ビュアは必ずしもこのチャンクを尊重しないことに注意してください。ビュアは異なる背景を使用することを選択できます。
カラータイプが 3 （インデックスカラー）では、bKGD は以下のものを格納します：
Palette index: 1 byte
値は背景として使われる色のパレットインデックスです。
カラータイプが 0, 4 （グレイスケール、α無し及び有り）では、bKGD は以下のものを格納します：
Gray: 2 bytes, range 0 .. (2^bitdepth)-1
（イメージのビット深度が 16 未満のとき、下位ビットが使われほかは 0 です）。値は背景として使われるグレイレベルです。
カラータイプが 2, 6 （トゥルーカラー、α無し及び有り）では、bKGD は以下のものを格納します：
Red: 2 bytes, range0 .. (2^bitdepth)-1Green: 2 bytes, range0 .. (2^bitdepth)-1Blue: 2 bytes, range0 .. (2^bitdepth)-1
（イメージのビット深度が 16 未満のとき、下位ビットが使われほかは 0 です）。これは、背景として使われる RGB カラーです。
bKGD が現れるときは、最初の IDAT チャンクの前に置かれ、PLTE チャンクが存在するならその後に置かれる必要があります。
デコーダへの勧告は：Background color を参照してください。
pHYs チャンクはイメージを表示するために意図されたピクセルサイズもしくはアスペクト比を指定します。いかのものを格納します：
Pixels per unit, X axis: 4 bytes (unsigned integer) Pixels per unit, Y axis: 4 bytes (unsigned integer) 単位指示子: 1 byte
単位指示子には以下の値が定義されています：
0: unit is unknown 1: unit is the meter
単位指示子が 0 のとき、pHYs チャンクはピクセルのアスペクト比のみを定義し、ピクセルの実際のサイズは未定義のままです。
換算注： 1 インチはぴったり 0.0254 メートルに等しい
この補助チャンクが存在しないときは、ピクセルは正方形と仮定され、それぞれのピクセルの物理的なサイズは未知です。
このチャンクが存在するときは、最初の IDAT チャンクの前に置かれる必要があります。
デコーダへの勧告は：Pixel dimensions を参照してください。
簡単なデコーダのために、PNG は確実に利用可能なサンプル深度しか定義していませんが、さらにそのサンプル深度でとりうるすべての範囲に拡大できるサンプル値を定義します。sBIT チャンクは元の有効なビット数を格納するために提供されます。これによってデコーダは PNG によって直接サポートされないサンプル深度を持つデータでさえも可逆的に元のデータに回復することができます。エンコーダは低サンプル深度からデータを変換したとき、sBIT チャンクを発行することを推奨されます。
カラータイプが 0 （グレイスケール）のとき、sBIT チャンクは元データで有効だったビット数を示す 1-byte を格納します。
カラータイプが 2 （トゥルーカラー）のとき、sBIT チャンクは元のデータで赤、緑、青のチャンネルそれぞれで有効だったビット数を示す 3-byte を格納します。
カラータイプが 3 （インデックスカラー）のとき、sBIT チャンクは元のデータで赤、緑、青のチャンネルのそれぞれで有効だったビット数を示す 3-byte を格納します。
カラータイプが 4 （αチャンネル付きグレイスケール）のとき、sBIT チャンクは元のグレイスケールデータと元のαデータそれぞれで有効だったビット数を示す 2-byte を格納します。
カラータイプが 6 （αチャンネル付きトゥルーカラー）のとき、sBIT チャンクは元のデータで赤、緑、青、αのチャンネルそれぞれで有効だったビット数を示す 4-byte を格納します。
sBIT で定義されるそれぞれの深度は 0 より大きく、サンプル深度（インデックスカラーのときは 8 、それ以外のカラータイプのときは IHDR で与えられるビット深度）以下である必要があります。
デコーダは sBIT に注意を払う必要はありません。保存されるイメージは IHDR で示されるサンプル深度で有効な PNG ファイルです。しかし、デコーダが元の精度で元のデータを復元しようとするならば、保存されているサンプル（インデックスカラーイメージのときは保存されているパレットエントリ）を右シフトすることでできます。エンコーダはこのような方法で高位ビットが元のデータと一致するようにデータを拡大する必要があります。
sBIT チャンクが存在するときは、最初の IDAT チャンクの前に置かれ、PLTE チャンクが存在するならその後に置かれる必要があります。
エンコーダへの勧告は：Sample depth scaling、デコーダへの勧告は：Sample depth rescaling を参照してください。
このチャンクは表示装置にイメージ中のすべての色の範囲を表示する能力がないときに使われる減色パレットを提案するために使われます。それは、PNG イメージを量子化できる減色パレットを構成することのできる、αや頻度の情報を含めた色の推奨セットを提供します。
このチャンクは NULL 終端を持つパレット名のテキスト文字列と 1-byte のサンプル深度、続いて 5 つの無符号整数を含む 6-byte または 10-byte のパレットエントリの連続を格納します：
Palette name: 1-79 bytes (character string) Null terminator: 1 byte Sample depth: 1 byte Red: 1 or 2 bytes Green: 1 or 2 bytes Blue: 1 or 2 bytes Alpha: 1 or 2 bytes Frequency: 2 bytes ...etc...
エントリはいくつでも存在できます。デコーダはサンプル深度よりあとの残りのチャンク長からエントリの数を決定します。残りのチャンク長が 6 で割り切れないとき（sPLT のサンプル深度が 8）や 10 で割り切れないとき（sPLT のサンプル深度が 16）は、エラーです。エントリは頻度の降順で現れる必要があります。エントリすべてがイメージで使われる必要はなく、すべてが異なっている必要もありません。
パレット名はパレットを参照する便利な名前ならなんでも可能です（たとえば、"256 color including Macintosh default"、"256 color including Windows-3.1 default", "Opimal 512" ）。アプリケーションや人間が PNG ファイルにひとつ以上推奨パレットが存在するときに適切に選ぶ助けとなるかもしれません。パレット名は大文字と小文字を区別し、 text キーワードと同じ制限を受けます。それは表示可能な Latin-1 [ISO/IEC-8859-1] 文字 (33-126, 161-255）と先頭や末尾を除いて連続しない空白（32）のみを格
sPLT のサンプル深度は 8 もしくは 16 である必要があります。
赤、緑、青、αのサンプルはそれぞれ、イメージのビット深度ではなく sPLT のサンプル深度に依存し、1-byte か 2-byte となります。色のサンプルは事前にαが乗算されることなく、背景と合成されることもありません。α値 0 は完全な透明を意味し、α値 255 （sPLT のサンプル深度が 8）または 65535 （sPLT のサンプル深度が 16）は完全な不透明を意味します。パレットのサンプルはその PNG イメージと同様のγ値と色度をもちます。
それぞれの頻度の値は RGBA 空間でパレットエントリと最も近い背景と合成される前のイメージ中のピクセルの割合に比例しています。実際の倍率はエンコーダによって選択されますが、個々の値が 0 から 65535 の範囲に収まるように選択されます。会社のロゴや写真の顔の特徴などの「重要な」色として人為的に頻度を増大させることも可能です。0 はその色が「重要でない」もしくは滅多に使われることがないということを意味し有効です。しかし、すべての頻度が 0 のとき、それらは意味を失います（実際の色の頻度から推測されるかもしれません）。
sPLT チャンクはどのカラータイプの PNG にも現れることができます。sPLT のエントリは PNG イメージの色空間をはずれることができます。たとえば、グレイスケールの PNG では、sPLT のエントリはふつう R=G=B を満足しますが、必要なわけではありません。同様に、sPLT のエントリは PNG イメージが透明を使っていないときでも不透明ではないα値を持つことができます。
sPLT が存在するときは、最初の IDAT チャンクの前に置かれる必要があります。複数の sPLT チャンクが存在することができますが、その場合それらは異なるパレット名を持つ必要があります。
エンコーダへの勧告は：Suggested palettes、デコーダへの勧告は：Suggested-palette and histogram usage を参照してください。
hIST チャンクはカラーパレットのそれぞれの色の使用頻度の概算を与えます。hIST チャンクは PLTE が現れるときのみ現れることができます。ビュアがパレットに列挙された色をすべて提供できないとき、ヒストグラムは表示のための色のサブセットをどのように選ぶかを決める助けとなるかもしれません。
hIST チャンクは連続した 2-byte (16-bit) の無符号整数格納します。PLTE チャンクのエントリごとにひとつずつのエントリが必要です。それぞれのエントリはそのパレットインデックスを持つイメージ中のピクセルの割合の比です。実際の倍率はエンコーダによって選ばれます。
ヒストグラムのエントリはパレットエントリがイメージ中で使われていないという 0 を除いて近似値です。その色のピクセルがあるとき、ヒストグラムのエントリは 0 でない必要があります。
パレットがトゥルーカラーイメージの推奨減色のとき、デコーダはエンコーダが行ったのとは異なるパレットエントリにピクセルを割り当てるかもしれないので、ヒストグラムは近似値である必要があります。このような状況では 0 のエントリは現れません。
sBIT チャンクが存在するときは、PLTE チャンクの後に置かれ、最初の IDAT チャンクの前に置かれる必要があります。
論拠は：Palette histograms 、デコーダへの勧告は：Suggested-palette and histogram usage を参照してください。
tIME チャンクはイメージが最終的に更新された時間を与えます（イメージが最初に生成された時間ではありません）。以下のものを格納します：
Year: 2 bytes (complete; for example, 1995, not 95)
Month: 1 byte (1-12)
Day: 1 byte (1-31)
Hour: 1 byte (0-23)
Minute: 1 byte (0-59)
Second: 1 byte (0-60) (yes, 60, for leap seconds; not 61,
a common error)
ローカルタイムよりユニバーサルタイム（UTC, GMT）を指定するべきでしょう。
tIME チャンクはイメージデータが変化したときはいつでもアップデートする自動タイムスタンプとして使われることを意図されています。tIME はイメージデータに変更を加えない PNG エディタによて変更されないよう勧告されています。text のキーワードの Creation Time は利用者が示す時間を使うことができます（text chunk specification を参照してください）。
この表は標準的なチャンク形式の属性の要約です。
必須チャンク（ PLTE が任意であることを除いて、
この順番で現れる必要があります）：
名前 複数個 順番の制限
OK?
IHDR No 最初
PLTE No IDAT の前
IDAT Yes 複数の IDAT は連続
IEND No 最後
補助チャンク（この順番で現れる必要はありません）：
名前 複数個 順番の制限
OK?
cHRM No PLTE、IDAT の前
gAMA No PLTE、IDAT の前
iCCP No PLTE、IDAT の前
sBIT No PLTE、IDAT の前
sRGB No PLTE、IDAT の前
bKGD No PLTE の後、IDAT の前
hIST No PLTE の後、IDAT の前
tRNS No PLTE の後、IDAT の前
pHYs No IDAT の前
sPLT Yes IDAT の前
tIME No None
iTXt Yes None
tEXt Yes None
zTXt Yes None
text チャンクの標準キーワード：
Title Short (one line) title or caption for image
Author Name of image's creator
Description Description of image (possibly long)
Copyright Copyright notice
Creation Time Time of original image creation
Software Software used to create the image
Disclaimer Legal disclaimer
Warning Warning of nature of content
Source Device used to create the image
Comment Miscellaneous comment; conversion from
GIF comment
追加的な公開 PNG チャンク形式は "Extensions to the PNG 1.2 Specification, Version 1.2.0"[PNG-EXTENSIONS] 文書に定義されています。そこに記述されているチャンクはこの仕様書に定義されているものよりも広いサポートをそれほど期待されていないものです。しかし、アプリケーションの製作者は彼らのアプリケーションに適当ならいつでもそれらのチャンクを使うことを勧められます。追加的なチャンク形式は PNG 仕様書の管理者 png-info@uunet.uu.net もしくは png-group@w3.org に連絡をとることによってリストに加えるえることを提案することができます。
新しい公開チャンクはほかの人に使われ、PNG の設計理念を破壊しない場合にのみ登録されるでしょう。潜在的に多くのアプリケーションが新しいチャンクを必要としているとき、チャンクが簡単に登録できることが作者たちの意図ではありますが、チャンクの登録は自動ではありません。新しい必須チャンク形式の作成は絶対的な必要性がない限りは進められないことに注意してください。
アプリケーションはほかのアプリケーションに関係のないデータを伝える私的なチャンクも使うことができます。エンコーダへの勧告：Use of private chunks を参照してください。
デコーダは認識できない公開もしくは私的なチャンク形式に出会ったときの準備をする必要があります。認識できないチャンク形式は Chunk naming conventions に記述されるように扱う必要があります。
