ポータブル・ネットワーク・グラフィックス（PNG）仕様書（第3版）

すべてのPNG画像には1つの静止画像が含まれます。

一部のPNG画像（Animated PNG（APNG）と呼ばれる）には、フレームベースのアニメーションシーケンス、すなわちアニメーション画像も含まれます。これは最初のフレームが—そうである場合も、そうでない場合もあります—静止画像であることがあります。アニメーション非対応の表示装置（プリンタなど）は、アニメーションシーケンスではなく静止画像を表示します。

静止画像およびアニメーション画像の各フレームは、それぞれ参照画像に対応し、PNG画像として格納されます。

本仕様はPNGデータストリームを規定し、PNGデータストリームを生成するPNGエンコーダ、PNGデータストリームを解釈するPNGデコーダ、および一つのPNGデータストリームを別のPNGデータストリームに変換するPNGエディタに対していくつかの要件を課します。アプリケーションとPNGエンコーダ／デコーダ／エディタ間のインタフェースは規定しません。エンコーダに提示される、またはデコーダにより出力される画像の正確な形式も規定しません。ここでは4種類の画像を区別します。

ソース画像

ソース画像は、PNGエンコーダに提示される画像です。

参照画像

参照画像は概念上のみ存在し、長方形のピクセルの長方形配列で構成され、すべて同じ幅と高さを持ち、すべて同じ数の符号なし整数サンプル（3つ（赤・緑・青）または4つ（赤・緑・青・アルファ））を含みます。同種（赤・緑・青・アルファ）の全サンプルの配列を チャネルと呼びます。各チャネルのサンプル深度は1〜16の範囲で、これはそのチャネル内のすべてのサンプルに用いられるビット数です。チャネルごとにサンプル深度が異なる場合があります。赤・緑・青サンプルはピクセルの色の赤・緑・青成分の強度を決定します。これらがすべてゼロならピクセルは黒、すべて最大値（2^sampledepth-1）なら白になります。アルファサンプルはピクセルの不透明度を決定し、ゼロは完全に透過、最大値は完全に不透明を意味します。3チャネルの参照画像では、すべてのピクセルは完全に不透明です。（4チャネルの参照画像でも全ピクセルが完全不透明である場合があります。この違いは、後者には特定のアルファのサンプル深度があるのに対し、前者にはない点です。）各水平方向のピクセル行はスキャンラインと呼ばれます。各スキャンライン内のピクセルは左から右へ、スキャンラインは上から下へ並びます。すべての参照画像はPNGデータストリームで正確に表現でき、すべてのPNGデータストリームは参照画像に変換できます。PNGエンコーダはソース画像を直接PNG画像に変換しても構いませんが、概念的にはまずソース画像を参照画像に変換し、その後参照画像をPNG画像に変換します。ソース画像の種類によっては、ソース画像から参照画像への変換で情報の損失を伴う場合があります。この変換はこの国際規格の範囲外です。ただし参照画像は、PNGデータストリームから常に完全に復元できます。

PNG画像

PNG画像は参照画像に次の一連の変換を適用して得られます：アルファ分離、 インデックス化、 RGB結合、アルファ圧縮、およびサンプル深度のスケーリング。PNG画像は5種類が定義されています（6.1 カラータイプと値参照）。（エンコーダがソース画像を実際に直接PNG画像へ変換し、ソース画像形式が既にPNG画像形式に近い場合、これらの変換の一部を省略できることがあります。）PNG画像では1〜16ビットのすべてのサンプル深度が明示的にサポートされるわけではありませんが、参照画像の各チャネルの有効ビット数を記録できます。PNG画像内のすべてのチャネルは同じサンプル深度を持ちます。PNGエンコーダはPNG画像からPNGデータストリームを生成します。PNGデコーダはPNGデータストリームを受け取り、PNG画像を再構成します。

出力画像

出力画像は、PNGデータストリームをデコードして得られたPNG画像から構築されます。出力画像の具体的な形式は規定しません。ビューアは、可能な限り元のソース画像の見た目に近い形で画像を提示します。

この4種類の画像の関係は、Figure 1に示します。

サンプル、チャネル、ピクセル、およびサンプル深度の関係は、Figure 2に示します。

色サンプルが位置付けられるRGBカラースペースは、次の4つの方法のいずれかで指定できます。

1. CICP画像フォーマットのシグナリングメタデータによる。
2. ICCプロファイルによる。
3. サンプルがこのカラースペースに準拠する場合、カラースペースがsRGBであることを明示する。
4. 画像で使用される赤・緑・青の各原色の1931 CIEのx,y色度と、参照ホワイトポイント、およびガンマ値を指定する。

ハイエンド用途では、最初の2つの方法が最も柔軟性と制御性を提供します。3つ目の方法は特定の（しかし非常に一般的な）カラースペースを示すのに有効です。4つ目の方法はICCプロファイルが広く採用される以前に標準化されたもので、RGBデータの正確な色度をガンマ補正とともに指定できます（C. ガンマと色度参照）。ただし、色管理対応アプリケーションは通常、最初の3つのいずれかを優先し、色管理非対応アプリケーションは通常、これら4つすべてを無視します。

Table 1は、カラースペース情報を提供するチャンクタイプの一覧で、それぞれに優先度（Priority）を割り当てています。単一の画像にこれらのチャンクタイプが複数含まれる場合、最も小さい優先度番号のチャンクが優先され、番号が大きいチャンクタイプは無視されるべきです。

ガンマ補正は、アルファチャネルが存在してもアルファチャネルには適用されません。アルファサンプルは常にフルレンジで、完全不透明に対する線形の割合を表します。

マスタリング用のメタデータを提供してもかまいません。

参照画像の変換結果は、5種類のPNG画像のいずれかになります（Figure 6参照）：

トゥルーカラー（アルファ付き）

各ピクセルは、赤・緑・青・サンプルとアルファの4サンプルで構成されます。

グレースケール（アルファ付き）

各ピクセルは、グレーサンプル1つとアルファサンプル1つの合計2サンプルで構成されます。

トゥルーカラー

各ピクセルは、赤・緑・青のサンプルからなる三つ組で構成されます。オプションのアルファチャネルは、赤・緑・青のサンプルの単一の三つ組として指定できます。画像中で赤・緑・青のサンプルがアルファチャネルの赤・緑・青のサンプルと同一であるピクセルは完全に透過であり、それ以外は完全に不透明です。アルファチャネルがない場合、すべてのピクセルは完全に不透明です。

グレースケール

各ピクセルは単一のグレーサンプルで構成され、これは黒から白までの全体的な輝度を表します。オプションのアルファチャネルは単一のグレーサンプルとして指定できます。画像中でグレーサンプルがアルファチャネルのグレーサンプルと同一であるピクセルは完全に透過で、それ以外は完全に不透明です。アルファチャネルがない場合、すべてのピクセルは完全に不透明です。

インデックスカラー

各ピクセルは、パレット（および存在する場合は関連するアルファ値テーブル）へのインデックスで構成されます。

各ピクセルのフォーマットは、PNG画像タイプとビット深度に依存します。インデックスカラー以外のPNG画像タイプでは、ビット深度はピクセルあたりの総ビット数ではなく、サンプルあたりのビット数を指定します。インデックスカラー画像では、ビット深度はパレットインデックスのビット数を指定し、パレット内の色やアルファテーブルのサンプル深度を指定するものではありません。ピクセル内でのサンプルの順序は、PNG画像タイプに応じて次の通りです。

1. トゥルーカラー（アルファ付き）：赤、緑、青、アルファ。
2. グレースケール（アルファ付き）：グレー、アルファ。
3. トゥルーカラー：赤、緑、青。
4. グレースケール：グレー。
5. インデックスカラー：パレットインデックス。

画像には補助情報を関連付けることができます。デコーダは、補助情報の全部または一部を無視してもかまいません。提供される補助情報の種類は、Table 2に記載しています。

PNGデータストリームのエラーは、一般に次の2つのクラスに分類されます。

1. データストリームの多くまたは全体を破損させる傾向がある、伝送エラーやコンピュータファイルシステムの損傷。
2. チャンク内の無効値や、欠落または誤配置されたチャンクとして現れる構文エラー。構文エラーはエンコードミスだけでなく、デコーダが未知の登録済みまたはプライベート値の使用によっても引き起こされ得ます。

PNGデコーダは、可能な限り早期にエラーを検出し、可能な場合はエラーから回復し、そうでない場合は穏やかに失敗すべきです。エラー処理の考え方については、13.1 エラー処理で詳述します。

PNGデータストリームは、PNGシグネチャに続くチャンク列で構成されます。これはPNG画像をエンコードした結果です。

PNGデータストリームの最初の8バイトは常に、次の16進値を含みます。

89 50 4E 47 0D 0A 1A 0A

このシグネチャは、データストリームの残りが単一のPNG画像を含み、IHDRチャンクで始まりIENDチャンクで終わる一連のチャンクから構成されていることを示します。

このシグネチャにより、PNGデータストリームは他の種類のデータストリームと区別され、いくつかの伝送エラーを早期に検出できるようになります。

各チャンクは3つまたは4つのフィールドで構成されます（Figure 10参照）。各フィールドの意味はTable 5に記載されています。チャンクデータフィールドは空であっても構いません。

チャンクデータの長さは最大値まで任意のバイト数になり得るため、実装者はバイトより大きな境界にチャンクが整列していると仮定してはなりません。

チャンクタイプは、そのバイトをISO 646の文字 [ISO646]として解釈したときに意味のある名称になるように選ばれます。チャンクタイプは、タイプが認識されない場合でもデコーダがチャンクの性質をある程度判断できるように割り当てられています。これらの規則により、PNGデコーダが未知のチャンクに遭遇した際の扱いを決定できるため、PNG形式の安全で柔軟な拡張が可能になります。

命名規則は通常、13. PNGデコーダとビューアで規定されるように、デコーダがチャンクタイプを認識しない場合にのみ関心の対象となります。

チャンクタイプの4つのビット、すなわち各バイトの第5ビット（値32）がプロパティビットとして、チャンクの性質を伝えるために使用されます。この選択により、人間がチャンクタイプの各バイトに対応する文字が大文字（ビット5が0）か小文字（ビット5が1）かによって、割り当てられた性質を読み取れます。

プロパティビットはチャンクタイプ固有の一部であり、したがって任意のチャンクタイプに対して固定です。したがって、CHNKとcHNkは、同じチャンクが異なる性質を持つのではなく、関連のない別個のチャンクタイプです。

プロパティビットの意味はTable 6に定義されています。

仮想的なチャンクタイプ「cHNk」のプロパティビットは次のとおりです。

cHNk  <-- 32 bit chunk type represented in text form
||||
|||+- Safe-to-copy bit is 1 (lower case letter; bit 5 is 1)
||+-- Reserved bit is 0     (upper case letter; bit 5 is 0)
|+--- Private bit is 0      (upper case letter; bit 5 is 0)
+---- Ancillary bit is 1    (lower case letter; bit 5 is 1)

したがって、この名称は、補助・パブリック・コピー安全なチャンクを表します。

CRCフィールドは、[ISO-3309]および[ITU-T-V.42]で定義される事前・事後条件付きの標準化されたCRC手法を用いて計算されます。採用されるCRC多項式（GZIPファイル形式仕様 [RFC1952]で使用されるものと同一）は次の通りです。

x³² + x²⁶ + x²³ + x²² + x¹⁶ + x¹² + x¹¹ + x¹⁰ + x⁸ + x⁷ + x⁵ + x⁴ + x² + x + 1

PNGでは、32ビットCRCはすべて1で初期化され、各バイトのデータは最下位ビット（1）から最上位ビット（128）へ処理されます。すべてのデータバイトが処理された後、CRCは反転されます（1の補数が取られます）。この値はMSBから順に送信（データストリームに格納）されます。バイトへの分割と順序付けのため、32ビットCRCの最下位ビットは、x31項の係数であると定義されます。

CRCの実用的な計算では、計算を高速化するためにあらかじめ計算されたテーブルがよく用いられます。D. サンプルCRC実装を参照してください。

各チャンクの配置に関する制約はTable 7に一覧し、静止画像についてはFigure 11およびFigure 12に模式的に示します。静止画像が最初のフレームを構成するアニメーション画像については、Figure 13およびFigure 14に、静止画像がアニメーションの一部でない場合はFigure 15およびFigure 16に示します。これらのラティス図は、本仕様によって課される配置上の制約を表します。図中の線は部分順序関係を定義します。上にあるチャンクは下にあるチャンクよりも前に現れなければなりません。水平方向に整列し、他の2種類のチャンク（その水平方向に整列したチャンクよりも上と下にある）に挟まれて現れるチャンクは、それら上位および下位のチャンクタイプの間で、任意の順序で現れて構いません。チャンクタイプに付された上付き文字の意味はTable 8で定義されます。これは、チャンクが必須か任意か、複数回現れ得るかを示します。2つのチャンクタイプの間の縦棒は代替を示します。

次のフィールドにおいて、128以上の値はプライベートフィールド値です。

• ビット深度
• カラータイプ
• 圧縮方式
• インターレース方式
• フィルタ方式

これらのプライベートフィールド値は、本仕様では定義も予約もされていません。

プライベートフィールド値は、実験的またはプライベートな意味のために使用MAYです。

プライベートフィールド値は、PNGデコーダで読み取り不能なデータストリームを生じ得るため（13. PNGデコーダとビューア参照）、公的に利用可能なソフトウェアやデータストリームには出現SHOULD NOTです。

4.5 PNG画像で説明したように、PNG画像には5種類があります。 各タイプに対応して、カラータイプがあり、これは次の値の総和です：1（パレット使用）、2（トゥルーカラー使用）、4（アルファ使用）。グレースケールおよびトゥルーカラー画像は明示的なアルファチャネルを持つことがあります。PNG画像タイプと対応するカラータイプはTable 9に示します。

各PNG画像タイプで許可されるビット深度とサンプル深度は、画像ヘッダに示します。

グレースケールサンプルは、転送曲線が（gAMA、 sRGB、iCCP、またはcICPにより）示されている場合は輝度を表し、示されていない場合はデバイス依存のグレースケールを表します。 RGBサンプルは、カラースペースが（gAMAとcHRM、sRGB、iCCP、またはcICPにより）示されている場合はキャリブレーション済みの色情報を表し、示されていない場合は非キャリブレーションのデバイス依存色を表します。

サンプル値は必ずしも光強度に比例しません。gAMAチャンクは、サンプル値と表示出力強度の関係を指定します。ビューアは適切に補正することが強く推奨されます。4.3 カラースペース、13.13 デコーダのガンマ処理、およびC. ガンマと色度を参照してください。

PNGデータストリームにおける透明性の表現は、PNG画像タイプに応じて4通りあります（4.4.1 アルファ分離および4.4.4 アルファ圧縮参照）。

1. トゥルーカラー（アルファ付き）、グレースケール（アルファ付き）：アルファチャネルが画像配列の一部です。
2. トゥルーカラー、グレースケール：tRNSチャンクが単一のピクセル値を含み、完全に透過なピクセルと完全に不透明なピクセルを区別します。
3. インデックスカラー：tRNSチャンクは、各パレットエントリに対応するアルファサンプルを関連付けるアルファテーブルを含みます。
4. トゥルーカラー、グレースケール、インデックスカラー：tRNSチャンクが存在せず、すべてのピクセルは完全に不透明です。

画像配列に含まれるアルファチャネルは、他のサンプルと同じサイズの8ビットまたは16ビットのサンプルを持ちます。各ピクセルのアルファサンプルは、そのピクセルのグレースケールまたはRGBサンプルの直後に格納されます。アルファ値0は完全透過を表し、2^sampledepth - 1の値は完全不透明を表します。 中間の値は部分的に透過なピクセルを示し、背景画像に合成することで出力画像を得られます。

ピクセル内の色値は、そのピクセルに割り当てられたアルファ値で事前乗算（premultiplied）されていません。この規則は「非関連（unassociated）」あるいは「非プリマルチプライド（non-premultiplied）アルファ」と呼ばれることがあります。（別の一般的な手法として、サンプル値をアルファ値で事前乗算して格納する方法があります。この場合、その画像は事実上黒背景に合成済みです。PNGはプリマルチプライドアルファを使用しません。その結果、画像エディタはPNG画像の透明度を容易に変更できます。）12.3 アルファチャネルの作成および13.16 アルファチャネル処理を参照してください。

1バイトを超える整数はすべてネットワークバイト順（Figure 17参照）でなければなりません。すなわち、最上位バイトが先で、その後に重要度の低いバイトが重要度の降順で続きます（2バイト整数ではMSB LSB、4バイト整数ではMSB B2 B1 LSB）。バイトの最上位ビット（値128）はビット7とし、最下位ビット（値1）はビット0とします。特に断りがない限り値は符号なしです。符号付きと明示された値は、2の補数表現で表されます。

PNG 4バイト符号なし整数は、符号なし4バイト値の扱いが困難な言語に配慮して、0から2³¹-1の範囲に制限されています。

PNG画像（またはパス。8. インターレースとパス抽出参照）は長方形のピクセル配列であり、各スキャンライン内ではピクセルは左から右へ、スキャンラインは上から下へ並びます。各ピクセルのサイズは、ピクセルあたりのビット数によって決まります。

スキャンライン内のピクセルは常に、ピクセル間に無駄なビットが生じないようバイト列に詰められます。スキャンラインは常にバイト境界から始まります。許可されるビット深度とカラータイプは、いずれの場合もパッキングが単純かつ効率的になるよう制限されています。

カラータイプ0（グレースケール）のPNG画像では、各ピクセルは1つのサンプルであり、1バイト未満の精度（1、2、または4ビット）を持つことがあります。これらのサンプルは、スキャンラインの左端のサンプルがバイトの上位ビットになるように、続くサンプルとともにバイトに詰められます。

カラータイプ3（インデックスカラー）のPNG画像では、各ピクセルは単一のパレットインデックスです。これらのインデックスは、カラータイプ0のサンプルと同様にバイトへ詰められます。

1バイトあたり複数のピクセルが含まれる場合、スキャンラインの最後のバイトの下位ビットの一部が未使用となることがあります。これら未使用ビットの内容は規定されません。

インデックスカラーでないPNG画像では、ビット深度16のサンプル値を持つことがあります。これらのサンプル値はネットワークバイト順（MSBが先、LSBが後）です。PNGでは複数サンプルのピクセルは8ビットまたは16ビットのサンプルに限られるため、単一ピクセルの複数サンプルが1バイトに詰められることはありません。

フィルタ方式は、スキャンライン配列に適用され、圧縮効率の向上を目的とした変換です。

PNGは1つのフィルタ方式と、圧縮に備えて画像データを準備するために使用できる複数のフィルタタイプを標準化しています。この変換は、フィルタタイプのバイトを先頭に付けた、同じ長さのバイト列へと変換します（例はFigure 18参照）。

エンコーダは、インターレースPNG画像に対して単一のフィルタ方式のみを使用しなければなりませんが、縮小画像の各スキャンラインごとに異なるフィルタタイプを使用しても構いません。賢いエンコーダはスキャンラインごとにフィルタを切り替えることができます。どのフィルタを使用するかの選択方法はエンコーダに委ねられます。

フィルタタイプのバイトは画像データの一部とは見なされませんが、圧縮ステップに送られるデータストリームには含まれます。9. フィルタ処理を参照してください。

この国際規格では、インターレース方式として0と1の2つを定義します。その他の値は将来の標準化のために予約されています。

インターレース方式0（ヌル方式）では、ピクセルは左から右へ順に抽出され、スキャンラインは上から下へ順に抽出されます。インターレースPNG画像は単一の縮小画像です。

インターレース方式1（Adam7として知られる）では、画像に対して7つの明確なパスを定義します。各パスは参照画像内のピクセルの部分集合を送信します。各ピクセルが送信されるパス（1から7までの番号）は、左上隅から画像全体に次の8×8パターンを繰り返すことで定義されます。

1 6 4 6 2 6 4 6
7 7 7 7 7 7 7 7
5 6 5 6 5 6 5 6
7 7 7 7 7 7 7 7
3 6 4 6 3 6 4 6
7 7 7 7 7 7 7 7
5 6 5 6 5 6 5 6
7 7 7 7 7 7 7 7

Figure 4.8は、インターレース方式1の7つのパスを示します。各パス内では、選択されたピクセルはスキャンライン内で左から右へ送信され、選択されたスキャンラインは上から下へ順に送信されます。例えば、パス2にはスキャンライン0、8、16、…のピクセル4、12、20、…が含まれます（スキャンライン0、ピクセル0は左上隅）。最後のパスにはスキャンライン1、3、5、…がすべて含まれます。送信順序は、各パスで送信されるすべてのスキャンラインが同じピクセル数になるように定義されています。これは一部のフィルタを適切に適用するために必要です。インターレースPNG画像は、7つの縮小画像の列で構成されます。例えば、PNG画像が16×16ピクセルの場合、第3パスは4ピクセルを含む2本のスキャンラインからなる縮小画像になります（Figure 4.8参照）。

スキャンラインが整数個のバイトを完全に満たさない場合、そのパディングは7.2 スキャンラインで定義されるとおりです。

フィルタ処理は、圧縮の改善を目的としてPNG画像を変換します。全体のプロセスはFigure 7に示され、スキャンラインの直列化とフィルタ処理の詳細はFigure 18に示されます。

PNGは複数のフィルタ方式を許容します。インターレース画像のすべての縮小画像は単一のフィルタ方式を使用しなければなりません。本仕様で定義されるのはフィルタ方式0のみです。他のフィルタ方式は将来の標準化のために予約されています。フィルタ方式0は5種類のフィルタタイプを提供し、各縮小画像内のスキャンラインごとに異なるフィルタタイプを使用できます。

PNGは、インターレースPNG画像に適用できるフィルタタイプに追加の制限を課しません。ただし、フィルタタイプはデータの種類によって効果が等しくはありません。12.7 フィルタ選択を参照してください。

フィルタ処理は、スキャンライン内のバイト列を、フィルタタイプを先頭に付けた同じ長さのバイト列へと変換します。フィルタタイプのバイトは非空のスキャンラインにのみ関連付けられます。空のパスにはフィルタタイプのバイトは存在しません。13.10 インターレースとプログレッシブ表示を参照してください。

フィルタは、画像のビット深度やカラータイプに関わらず、ピクセルではなくバイトに対して適用されます。フィルタは、7.2 スキャンラインで説明された表現に従って構成されたスキャンラインのバイト列に対して動作します。画像にアルファチャネルが含まれる場合、アルファデータは画像データと同様にフィルタ処理されます。

フィルタは、新しいバイト値を生成するために、以下のバイトの元の値を使用することがあります。

Figure 19は、x、a、b、cの相対位置を示します。

フィルタ方式0は、Table 11に示す5つの基本フィルタタイプを定義します。Orig(y)はバイトyの元の（非フィルタ）値を表します。Filt(y)はフィルタタイプを適用した後の値を表します。Recon(y)は対応する再構成関数を適用した後の値を表します。PaethフィルタタイプのPaethPredictor [Paeth]は後述します。

フィルタ方式0は、ちょうどこの5つのフィルタタイプの集合を規定しており、これを拡張してはなりません。これにより、デコーダはデータを伸長しなくても、未サポートのフィルタタイプが含まれているかどうかを判断できます。11.2.1 IHDR 画像ヘッダ内のフィルタ方式を確認するだけで十分です。

すべてのフィルタにおいて、スキャンラインの最初のピクセルの「左にある」バイトは0として扱われなければなりません。前のスキャンラインを参照するフィルタでは、縮小画像の最初のスキャンラインにおいて、前のスキャンライン全体とその最初のピクセルの「左にある」バイトは0として扱われなければなりません。

フィルタの効果を逆にするには、同じスキャンライン上の直前のピクセルの復号値、前のスキャンラインで現在のピクセルの直上にあるピクセルの復号値、そしてその直上のピクセルの左隣のピクセルの復号値が必要です。

入出力の両方をバイトに収めるため、256を法とする符号なし算術を用います。フィルタはビット深度に関係なく各バイトに適用されます。Filt値の列が、フィルタ済みスキャンラインとして送信されます。

Orig(a) + Orig(b)の和はオーバーフローなし（少なくとも9ビットの算術）で実行されなければなりません。floor()は、除算の結果が小数であれば次に小さい整数に切り下げることを示します。言い換えれば、これは整数除算または右シフト演算です。

Paethフィルタタイプは、3つの隣接ピクセル（左、上、左上）の単純な線形関数を計算し、その値に最も近い隣接ピクセルを予測値として選択します。本仕様で用いるアルゴリズムは、Alan W. Paethによる手法の改変です（[Paeth]）。

PaethPredictor関数は以下のコードで定義されます。関数のロジックと、バイトa、b、c、xの位置はFigure 20に示します。Prはバイトxの予測値です。

p = a + b - c
pa = abs(p - a)
pb = abs(p - b)
pc = abs(p - c)
if pa <= pb and pa <= pc then Pr = a
else if pb <= pc then Pr = b
else Pr = c
return Pr

PaethPredictor関数内の計算は、オーバーフローなしで厳密に実行されなければなりません。

比較の実行順序は重要であり、変更してはなりません。この関数は、（垂直、水平、対角の）3方向のうち、画像の勾配が最も小さい方向を見つけようとします。

エンコーダとデコーダは、まったく同一のPaethPredictor関数を使用します。

本国際規格で定義されるPNGの圧縮方式は方式0のみです。その他の圧縮方式の値は将来の標準化のために予約されています。PNG圧縮方式0は、スライディングウィンドウ（deflateストリームに現れる距離の上限）最大32768バイトのdeflate圧縮です。Deflate圧縮はLZ77に由来します。

PNG内のdeflate圧縮データストリームはzlibフォーマットで格納され、その構造は次のとおりです。

zlibは[rfc1950]で規定されています。

PNG圧縮方式0では、zlibの圧縮方式/フラグコードは方式コード8（deflate圧縮）および32768バイト以下のLZ77ウィンドウサイズを指定しなければなりません。なお、zlibの圧縮方式番号は、IHDRチャンクにおけるPNGの圧縮方式番号と同一ではありません。追加フラグでプリセット辞書を指定してはなりません。

圧縮対象データが16384バイト以下である場合、PNGエンコーダはウィンドウサイズを2の累乗（最小256）に切り上げて設定してもかまいません。これは圧縮率に悪影響を与えることなく、エンコードおよびデコードの両方に必要なメモリを削減します。

zlibデータストリーム内の圧縮データは、一連のブロックとして格納されます。各ブロックは生（非圧縮）データ、固定ハフマン符号で符号化されたLZ77圧縮データ、またはカスタムハフマン符号で符号化されたLZ77圧縮データのいずれかを表します。最終ブロックのマーカビットはそれが最後のブロックであることを示し、デコーダが圧縮データストリームの終端を認識できるようにします。圧縮アルゴリズムと符号化の詳細は、deflate仕様[rfc1951]に記載されています。

zlibデータストリーム末尾に格納されるチェック値は、そのデータストリームが表す非圧縮データに対して計算されます。この計算に用いられるアルゴリズムは、PNGのチャンクCRCフィールド値に用いられるCRC計算と同一ではありません。zlibのチェック値は、主としてdeflateアルゴリズムが正しく実装されていることを相互確認するために有用です。各PNGチャンクのCRCを検証することで、PNGデータストリームが損傷なく伝送されたことに確信が持てます。

フィルタ済みスキャンラインの列は圧縮され、その結果得られたデータストリームはIDATチャンクに分割されます。すべてのIDATチャンクの内容を連結したものが1つのzlibデータストリームとなります。このデータストリームは伸長されるとフィルタ済みの画像データになります。

IDATチャンク間の境界は任意であり、zlibデータストリームのどこにでも置かれ得ることを強調しておくことが重要です。IDATチャンク境界とdeflateブロック境界、またはその他のzlibデータの特徴との間に相関があるとは限りません。例えば、終端のzlibチェック値がIDATチャンクにまたがって分割されることも十分あり得ます。

同様に、画像データの構造（すなわちスキャンライン境界）とdeflateブロック境界やIDATチャンク境界との間に必要な相関はありません。完全なフィルタ済みPNG画像は、複数のIDATチャンクに格納された単一のzlibデータストリームで表現されます。

PNGはiTXt、iCCP、およびzTXtチャンクにおいても圧縮方式0を使用します。画像データとは異なり、これらのデータストリームはチャンクをまたいで分割されません。各チャンクは独立したzlibデータストリームを含みます（10.1 圧縮方式0参照）。

本節では本仕様で使用されるチャンクを定義します。

簡単なガンマの導入については C. Gamma and chromaticity を参照してください。

フルカラーマネジメント対応の PNG エンコーダは、ここで説明するよりも高度な計算を行い、iCCP チャンクを使用することを選択する場合があります。もしイメージのサンプルが sRGB 仕様 [SRGB] に準拠していることが分かっているなら、エンコーダは追加のガンマ処理を行わずに sRGB チャンクを書き込むことが強く推奨されます。どちらの場合でも、iCCP や sRGB チャンクを認識しない PNG デコーダ向けに、適切な gAMA チャンクを生成することが推奨されます。

PNG エンコーダは以下を決定する必要があります：

1. どの値を gAMA チャンクに書き込むか；
2. 提供されたイメージサンプルを PNG データストリームに書き込む値にどのように変換するか。

gAMA チャンクに書き込むべき値は、PNG デコーダが期待通りに動作するようにする値です。13.13 Decoder gamma handling を参照してください。

適用すべき変換は、イメージサンプルの性質とその精度に依存します。もしサンプルが浮動小数点や高精度整数で光強度を表している場合（たとえばコンピュータグラフィックスのレンダラから）、エンコーダは PNG データストリームに含めるために整数へ量子化する前に ガンマエンコーディング（指数が1未満のべき関数を適用）を実行することがあります。これにより与えられたサンプル深度でバンディングのアーティファクトが少なくなったり、同等の視覚品質を保ちながらより小さなサンプルを使えたりします。0 から 1 の範囲の浮動小数点値で表現された強度レベルは、次の式でデータストリームのイメージサンプルに変換できます：

integer_sample = floor((2sampledepth-1) * intensityencoding_exponent + 0.5)

式中の intensity が望ましい出力強度を表す場合、encoding_exponent は gAMA チャンクに使用する gamma value になります。

もしエンコーダが利用できる強度が元のシーン強度であるなら、別の変換が必要になることがあります。表示画像が元のソース画像よりコントラストを高くする必要がある場合があります。これは元のシーンから表示出力へのエンドツーエンドの 伝達関数 が 1 より大きい指数を持つことに対応します。この場合：

gamma = encoding_exponent/end_to_end_exponent

もし元の画像がキャプチャまたは計算された条件がそのようなコントラスト変化を正当化するか不明な場合、表示強度は元のシーン強度に比例すると仮定してよい（すなわち end_to_end_exponent は 1）ので：

gamma = encoding_exponent

もし画像がデータストリームにのみ書き込まれるのであれば、エンコーダはエンコーディング指数を自由に選べます。gAMA チャンクに 1/2.2 を与えるような値を選ぶことは、多くの場合妥当です。なぜなら典型的なビデオモニタ上で表示する PNG デコーダの負担を最小にするからです。

いくつかのイメージレンダラはイメージを PNG データストリームへ書き込むと同時に画面にも表示することがあります。表示されるピクセルは、その表示システムと視聴条件に合わせてガンマ補正されるべきであり、ユーザが意図したシーンの適切な表現を目にするようにすべきです。

もしレンダラが画面上に表示されたサンプル値を PNG データストリームへ書き込みたい（データストリームのために別個の ガンマエンコーディング ステップを回避したい）場合、レンダラは表示システムの 伝達関数 をべき関数で近似し、その指数の逆数を gAMA チャンクに書き込むべきです。これにより PNG デコーダはレンダリング中に作成者が画面で見たものを再現できます。

しかしながら、レンダラが表示デバイスに適した表示ピクセルを計算し、データ保存用に別途 ガンマエンコーディング を実行し、将来の使用により適した値を gAMA に入れるようにすることも同様に合理的です。

コンピュータグラフィックスのレンダラはしばしば ガンマエンコーディング を行わず、サンプル値をシーン光強度に直接比例させることが多いです。もし PNG エンコーダが既に整数に量子化されたサンプル値を受け取るなら、それに対して再び ガンマエンコーディング を行う意味はありません；単に情報損失を招くだけです。エンコーダはサンプル値をそのまま PNG データストリームへ書き込むべきです。これは gAMA チャンクに 1.0 を入れるべきだという意味ではありません。なぜならシーン強度から表示出力への望ましいエンドツーエンドの 伝達関数 が線形であるとは限らないからです。しかし望ましい gamma value はおそらく 1.0 に近いでしょう。これはレンダリングされているシーンが屋外の昼光シーンか室内シーンか等に依存するかもしれません。

サンプル値がハードウェアから直接来る場合、正しい gAMA 値は理論上ハードウェアの 伝達関数 とシーンの照明条件から推定できます。ビデオのフレームグラバのような場合、サンプルはおそらく sRGB カラースペースにあるでしょう。イメージスキャナの出力は予測しにくく、CCD センサ自体は線形であるため入力光強度に比例する場合もあれば、スキャナハードウェアが印刷でのドットゲイン補正用のべき関数を既に適用している場合（約 0.57 の指数）や、モニタ表示用に補正済みの場合もあります。特定のスキャナの特性を知るにはマニュアルや校正ターゲットのスキャンが必要になることがあります。gamma はサンプルと望ましい表示出力との関係を表すものであって、スキャナ入力そのものには関係しない点を忘れないでください。

データストリーム形式の変換器は、一般に供給された画像のガンマを別のものへ変換しようとするべきではありません。データは変換せずに PNG データストリームへ保存されるべきであり、可能ならソースデータストリームから gamma value を推定して書き込むべきです。データストリーム変換時のガンマ変更は、表現される強度レベル集合の再量子化を引き起こし、利点がほとんどないまま丸め誤差を追加します。入力から出力へサンプル値をそのままコピーする方がほとんどの場合良いでしょう。

もしソースデータストリームが画像の gamma 特性を記述しているなら、データストリーム変換器は gAMA チャンクを書くことが強く推奨されます。一部の形式は表示指数（画像サンプルを表示出力へマップする関数の指数）を指定します。もしソースファイルの gamma value が 1.0 より大きいなら、それはおそらく表示指数であり、その逆数を PNG の gamma value に使うべきです。もしソースファイルが画像サンプルと表示出力以外の量との関係を記録している場合、PNG の gamma value を推定するのはもっと複雑になります。

もし PNG エンコーダやデータストリーム変換器が、表示システムの 伝達関数 をべき関数で近似できることを知っているなら、その指数を display_exponent として、イメージには次の gamma value を付与できます：

gamma = 1/display_exponent

おおよそ正しい値の gAMA チャンクを書き込む方が、チャンクを省略して PNG デコーダに適当な gamma value を推測させるよりも望ましいです。もし PNG エンコーダが gamma value を推定できないなら、gAMA チャンクを省略する方が望ましいです。推測しなければならない場合は、それを PNG デコーダに任せるべきです。

gamma はアルファサンプルには適用されません；アルファは常に線形で表されます。

また 13.13 Decoder gamma handling も参照してください。

色に関する参考は C. Gamma and chromaticity を参照してください。

フルカラーマネジメント対応の PNG エンコーダは、ここで述べるより高度な計算を行い、iCCP チャンクを使用することを選ぶかもしれません。もしイメージサンプルが sRGB 仕様に準拠すると分かっているなら、PNG エンコーダは sRGB チャンクを使用することが強く推奨されます。

ソースの表示原色の色度を決定できる、または画像の起源や実行ハードウェアに基づいて強い推測ができる場合、エンコーダは cHRM チャンクを出力することが強く推奨されます。もしそれを行うなら、gAMA チャンクも併せて書き込むべきです；デコーダは cHRM だけではあまり利用できません。

原色や ホワイトポイント に関してはいくつかの推奨や標準があり、技術に結びつくものもあります。たとえば CCIR 709 [ITU-R-BT.709] や SMPTE-C [SMPTE-170M] などです。

考慮すべきケースは次の三つです：

1. エンコーダが生成システムの一部である場合；
2. ソース画像がカメラやスキャナでキャプチャされた場合；
3. PNG データストリームが他の形式から変換によって生成された場合。

手描きやデジタル編集された画像の場合、制作時にどのモニタで表示していたかを特定する必要があります。多くの画像編集プログラムは使用中のモニタ種別を指定でき、内部でデバイス非依存空間を使っていることが多いです。そのようなプログラムは有効な cHRM および gAMA チャンクを書き込むのに十分な情報を持っており、自動的にそれらを書き込むことが強く推奨されます。

エンコーダがフルスペクトルレンダリングを行うコンピュータレンダラの一部としてコンパイルされている場合、内部のデバイス非依存色空間から RGB へ変換するために使用したモニタ値を cHRM チャンクに書くべきです。選択した RGB デバイスのガモット外の色はガモット内にマップされるべきです；PNG はガモット外の色を格納しません。

もしコンピュータレンダラがデバイス依存の RGB 空間で直接計算を行うなら、シーン記述とレンダリングパラメータが特定のモニタに合わせて調整されていない限り cHRM チャンクは書くべきではありません。その場合は、そのモニタのデータを使って cHRM チャンクを構築すべきです。

一部のイメージ形式はキャリブレーション情報を格納しており、それを使って cHRM チャンクを埋めることができます。たとえば TIFF 6.0 [TIFF-6.0] はオプションでキャリブレーション情報を持ち、存在するなら cHRM チャンクの構築に使うべきです。

最近のビデオ機器で作成されたビデオはおそらく CCIR 709 の原色と D65 のホワイトポイントを使用しており、これらは Table 29 に示されています。

古くから広く使われているビデオ標準の一つに SMPTE-C [SMPTE-170M] があり、これは Table 30 に示されています。

データストリーム形式の変換器が供給された画像を別の RGB カラースペースへ変換しようとすることは推奨されません。データは変換せずに PNG データストリームに格納されるべきであり、ソースの原色色度が分かっていればそれを記録すべきです。データストリーム変換時の色空間変換は、ガモットの不一致や丸め誤差のために悪い考えです。ガンマ変換と同様に、データをロスレスに格納し、最終的な表示時に多くても一度だけ変換を行う方が良いのです。

また 13.14 Decoder color handling を参照してください。

アルファチャネルは、透明な部分を一時的に隠すマスクとして考えることも、非矩形イメージを構築する手段と考えることもできます。前者の場合、完全に透明なピクセルの色値は将来の利用のために保持するべきです。後者の場合、透明ピクセルは有用なデータを持たず、PNG が要求する矩形イメージ領域を満たすために存在するだけです。この場合、完全に透明なピクセルには圧縮のために同一の色値を割り当てるべきです。

イメージ作者は、デコーダが透明性制御を完全にはサポートしない可能性があることを念頭に置くべきです（13.16 Alpha channel processing を参照）。したがって、可能であれば透明ピクセルに割り当てる色は合理的な背景色にしておくべきです。

完全なアルファチャネルを必要としない、あるいは圧縮効率の面で許容できないアプリケーション向けに、tRNS 透過チャンクも利用可能です。

もしイメージに既知の背景色があるなら、その色は bKGD チャンクに書き込むべきです。透明性を無視するデコーダであっても、bKGD の色を未使用領域の塗りつぶしに使うことができます。

もし元の画像がプリマルチプライド（associated）アルファを持つ場合、それを PNG の非プリマルチプライド形式へ変換するには、各サンプル値を対応するアルファ値で割り、次に画像ビット深度の最大値を掛け、最も近い整数へ丸めればよいです。有効なプリマルチプライドデータでは、サンプル値が対応するアルファ値を超えることはないので、除算の結果は常に 0 〜 1 の範囲になるはずです。もしアルファ値がゼロなら、出力は黒（ゼロ）にしてください。

PNG で直接表現できないサンプル深度の入力サンプルをエンコードする場合、エンコーダはサンプルを PNG が許容するサンプル深度へ拡大スケールしなければなりません。最も正確なスケーリング方法は線形式です：

output = floor((input * MAXOUTSAMPLE / MAXINSAMPLE) + 0.5)

ここで入力サンプルは 0 から MAXINSAMPLE の範囲で、出力は 0 から MAXOUTSAMPLE（これは 2^sampledepth-1）までの範囲です。

線形スケーリングに近い近似は「左ビット複製（left bit replication）」によって得られます。これは有効ビットを最上位ビットにシフトし、開いている下位ビットへ最上位ビットを繰り返して埋める方法です。この方法は線形スケーリングより計算が速いことが多いです。

例えば 5 ビットサンプルを 8 ビットへ拡大する場合を考えます。ソースサンプル値が 27（0-31 の範囲）であれば、元のビットは：

4 3 2 1 0
---------
1 1 0 1 1

左ビット複製は値 222 を与えます：

7 6 5 4 3  2 1 0
----------------
1 1 0 1 1  1 1 0
|=======|  |===|
    |      Leftmost Bits Repeated to Fill Open Bits
    |
Original Bits

これは線形式で計算した値と一致します。左ビット複製は通常線形スケーリングと同じ値を与え、最大でも 1 だけ差が出ることはありません。

より精度の低い近似は単に入力値を左シフトして下位ビットをゼロで埋める方法です。この方式は最大値が全て 1 にはならないため白を正確に再現できず、結果として画像がわずかに暗くなります。一般にはこの方法は推奨されませんが、特に 8 ビットより大きなサンプル深度を扱うときに圧縮が改善される効果があります。高いサンプル深度ではゼロフィルスケーリングによる相対誤差は小さいため、いくつかのエンコーダはこれを選ぶかもしれません。ただしアルファチャネルデータに対してゼロフィルは使用してはなりません。多くのデコーダはアルファ値が全ゼロや全 1 の場合を特別扱いするからです。スケーリング後のデータではこれらの値を正確に表現することが重要です。

エンコーダが sBIT チャンクを書き込む場合、格納されたサンプルの高位ビットが元のデータと一致するようにスケーリングを行うことが要求されます。すなわち、もし sBIT が S ビットのサンプル深度を示す場合、格納データの高位 S ビットは元の S ビット値と一致しなければなりません。これによりデコーダは右シフトして元のデータを復元できます。追加される下位ビットには制約がありません。上述のスケーリング方法はすべてこの制約を満たします。

ソースのイメージデータをスケールアップする際、下位ビットはすべてのサンプルで一貫して埋めることが推奨されます。すなわち同じソース値はどの画素位置でも同じ生成サンプル値を生むべきです。これにより異なるサンプル値の数が減り圧縮が改善されます。これは必須ではなく、一部のエンコーダはむしろ下位ビットにディザを施して表示品質を向上させる代わりにファイルサイズを増やすことを選ぶ場合があります。

一部の用途では元のソースデータのレンジが 2 の冪でないことがあります。その場合でも線形スケーリング式は機能しますが、シフト法は適しません。そのような画像では sBIT を書かないことが推奨されます。なぜなら sBIT は元のデータレンジが正確に 0..2^S-1 であったことを示唆してしまうからです。

推奨パレットは任意の PNG データストリーム内で sPLT チャンクとして、あるいは PLTE チャンクとして（truecolor の PNG データストリームにおいて）出現することがあります。いずれの場合も、推奨パレットは image data の本質的な一部ではありませんが、インデックスカラ表示ハードウェア上でイメージを表示するために使われ得ます。推奨パレットは truecolor ハードウェア上で動作するビューアには興味がないことがあります。

sPLT チャンクを用いて推奨パレットを提供する場合、エンコーダは周波数フィールドを すべてゼロ（未定義）にせず、パレットエントリの相対的重要性を示すために使用することが推奨されます。周波数値は「最近傍」カウント、すなわちディザを適用しない場合に各 RGBA パレットエントリがどれだけ使われるかの概算として最も容易に計算できます。（これらのカウントは推奨パレットを作る過程で「無料で」得られることが多いです。）推奨パレットは透明情報を含むため、合成されていないイメージに対して計算するべきです。

インデックスカラー画像であっても、sPLT は表示可能色の少ないビューア向けの代替縮小パレットを定義するために使用できます。もし PLTE が bKGD なしで color type 6 のイメージに現れる場合、パレットがどのような状況で計算されたかは未定義です。

truecolor PNG データストリームに推奨パレットを含める古い方法として PLTE チャンクを用いるものがあります。この方法を使うならヒストグラム（周波数）は別の hIST チャンクに置くべきです。PLTE チャンクは透明情報を含まないため、color type 6（truecolor with alpha）の画像では、bKGD チャンクが現れること、そしてパレットとヒストグラムは指定された背景色に対して合成された後の画像を基準に計算されることが推奨されます。この定義は、分数アルファ値を持つピクセルに対して有用なパレットエントリを生成するために必要です。結果のパレットはおそらく同じ背景色で画像を提示するビューアにのみ有用でしょう。PNG エディタ が bKGD を変更または削除する場合、パレットを削除または再計算することが推奨されます（color type）。

color type 2（truecolor）の画像に対しては、PLTE と hIST は透明色の指定を無視して RGB データのみを基準に計算することが推奨されます。もしデータストリームが透過を使っている（tRNS を持つ）場合、ビューアは意図する背景色に合わせて生成されたパレットを容易に適応させることができます（13.17 Histogram and suggested palette usage を参照）。

推奨パレットを提供するにあたり、sPLT チャンクは PLTE チャンクより柔軟です：

1. sPLT では複数の推奨パレットを提供できます。PNG デコーダは名前やエントリ数に基づいて適切なパレットを選択できます。
2. PNG データストリームが color type 6 の場合、PLTE チャンクは bKGD 色に対して既に合成されたパレットを表すため、その背景色に対してのみ有用です。sPLT は合成されていないパレットを提供し、デコーダが選ぶ背景に対して有用です。
3. sPLT は補助チャンクであるため、PNG エディタ は未知の安全でないコピー不可チャンクを破棄することを強制されることなく推奨パレットを追加・修正できます。
4. sPLT はカラータイプ 0, 3, 4 の PNG データストリームにも許されますが、これらの場合 PLTE は縮小パレットの提供には使えません。
5. sPLT には 256 を超えるエントリが現れることがあります。

sPLT を使う PNG エンコーダは、sPLT を認識しないデコーダとの互換性のために、PLTE と hIST を併せて書き込むことを選べます。

本仕様は 2 種類のインターレース方式（そのうち一つはインターレースなし）を定義します。インターレースはデコーダが画像をプログレッシブに表示するための便利な基盤を提供します（13.10 Interlacing and progressive display を参照）。

color type 3（インデックスカラー）の画像では、フィルタタイプ 0（None）が通常最も効果的です。色数が 256 以下のカラー画像はほとんど常に indexed-color 形式で保存されるべきであり、truecolor 形式ははるかに大きくなる傾向があります。

ビット深度が 8 未満の画像にもフィルタタイプ 0 が推奨されます。低ビット深度のグレースケール画像では、稀に画像をまず 8 ビット表現へ展開してからフィルタを適用することでより良い圧縮が得られることがあります。

truecolor および greyscale の画像では、5 種類のいずれのフィルタが最も効果的かは画像に依存します。固定フィルタを用いるなら Paeth フィルタが最も良いことが多いです。

truecolor および greyscale 画像の最高の圧縮を得るため、もし圧縮効率を速度より重視するなら、各スキャンラインごとにフィルタタイプを選ぶ適応フィルタリングが推奨されます。各画像はそれぞれ最適なフィルタの組合せを持ちます。エンコーダは全てのフィルタの組合せを試して最も圧縮されるものを見つけることもできますが、全探索が許容できない場合、次のような一般的ヒューリスティックが有効です：各スキャンラインについて 5 種類のフィルタすべてを適用して、出力バイトの絶対値の和が最小となるフィルタを選びます（このテストでは出力バイトを符号付き差分として扱ってください）。この方法は単一の固定フィルタを選ぶより通常優れます。

これらの推奨に基づくフィルタ適用は、本仕様で定義されたいずれのインターレース方式と組み合わせても効果的です。

エンコーダは圧縮データストリームを任意に IDAT チャンクへ分割できます。（複数の IDAT チャンクは、エンコーダが固定量のメモリで動作できるようにするために許可されています；通常チャンクサイズはエンコーダのバッファサイズに対応します。）各 IDAT チャンクが 1 バイトのみのデータを含むような PNG データストリームも有効ですが、著しく無駄です。（ゼロ長 の IDAT チャンクも有効ですが、さらに無駄です。）

各テキストチャンクには空でないキーワードを付ける必要があります。もし適切な説明がない場合は汎用キーワード "Comment" を使えます。ユーザ提供のキーワードを使う場合、エンコーダはそのキーワードがキーワードの制限に合致しているかをチェックすべきです。

iTXt チャンクは Unicode の UTF-8 エンコーディングを使うため任意の言語のテキストを格納できます。tEXt および zTXt は Latin-1（ISO 8859-1）を使い、これらのチャンクで使用できる文字の範囲を制限します。エンコーダは文字の範囲を広くしてデータ損失を避けるために iTXt を tEXt や zTXt より優先して使うべきです。エンコーダはローカルのレガシー文字エンコーディングを適切なエンコーディングへ変換してテキストを保存しなければなりません。

iTXt チャンクを作成する際、エンコーダは UTF-8 encode（Encoding Standard）に従うべきです。

エンコーダは 79 個を超える Unicode の code point からなる単一行テキストの作成を思いとどまらせるべきで、読みやすさを促進するべきです。1024 バイト未満のテキスト項目は非圧縮テキストチャンクで出力することが推奨されます。基本的なタイトルや作成者キーワードは非圧縮テキストチャンクで出力することが推奨されます。大きなテキストチャンクを 画像データ の後（すなわち IDAT チャンクの後）に置くと、状況によっては画像表示を速くできることがあります。小さなテキストチャンク（画像タイトルなど）は IDAT チャンクの前に置くことが推奨されます。

PNG データストリームのエラーは大きく二つのクラスに分かれます：伝送エラーと構文エラーです（4.10 Error handling を参照）。

伝送エラーの例としては、バイトコード 13 および/または 10 がデータストリーム全体にわたって追加・削除・変換される「text」や「ascii」モードでの伝送、データストリームが切断される予期しない終了、あるいは記憶装置上の物理エラーでブロック（通常 512 バイト単位）が乱れたりランダムな値になる場合などがあります。構文エラーの例としては、行フィルタの無効な値、無効な圧縮方式、無効なチャンク長、インデックス画像で最初の IDAT チャンクの前に PLTE チャンクがないこと、あるいは複数の gAMA チャンクの存在などがあります。PNG デコーダは次のようにエラーを処理するべきです：

1. PNG シグネチャバイトや各チャンクの CRC を用いて、できるだけ早期にエラーを検出すること。デコーダは PNG シグネチャの全 8 バイトが正しいことを検証すべきです。次の 8 バイトが正しいチャンク長を持つ IHDR チャンクで始まる場合、データストリームの整合性に対する追加の信頼が得られます。チャンクデータを処理する前に CRC をチェックするべきです。ストリーミング PNG デコーダが大きな IDAT チャンクを処理しているような場合は実用上難しいことがありますが、その場合はチャンク終端に到達した時点で CRC をチェックすべきです。
2. 可能ならばエラーから回復し、そうでなければ優雅に失敗すること。画像処理にほとんど影響のないエラーは無視できる一方、重要なデータに影響するエラーはアプリケーションに適した方法で扱うべきです。
3. 回復可能なエラーを含め、エラーを説明する有用なメッセージを提供すること。

この方針に関連する PNG チャンクのクラスは三種類あります。この分類における「未知のチャンク」とは、デコーダ作成者にとって真に型が不明なチャンク、あるいは作成者が扱いを既定の方法（デフォルトハンドリング）に任せたために「未知」と扱うことにしたチャンクを指します。他のチャンクは「既知のチャンク」と呼ばれます。この定義に基づく三つのクラスは次のとおりです：

1. 既知のチャンク。これは本仕様で定義されたすべてのクリティカルチャンク（IHDR, PLTE, IDAT, IEND）を必ず含みます。
2. 未知のクリティカルチャンク（チャンクタイプの最初のバイトのビット5が 0）
3. 未知の補助（ancillary）チャンク（チャンクタイプの最初のバイトのビット5が 1）

チャンク命名規約の説明は 5.4 Chunk naming conventions を参照してください。

PNG チャンクの型は、表示可能なイメージを取り出すために重要かどうか（IHDR, PLTE, IDAT のように）あるいはデータストリーム構造を理解するために重要かどうか（IEND のように）に応じて「critical」または「ancillary」に分類されます。これは特定の種類の重要度であり、あらゆるデコーダに必ずしも関連するとは限りません。例えば注釈（例えば著作権情報）を抽出するだけのプログラムは表示可能なイメージを必要としませんが、UTF-8 を正しくデコードするべきです。別のデコーダは tRNS や gAMA チャンクを実行上必須と考えるかもしれません。

構文エラーは常に既知のチャンクに関するものです。未知チャンクの構文エラーは検出できないためです。PNG デコーダは状況と要件に応じて構文エラーが致命的（回復不能）かどうかを判断しなければなりません。例えば多くのデコーダは無効な IEND チャンクを無視できます；テキスト抽出プログラムは IDAT の欠如を無視できます；画像ビューアはインデックス画像における空の PLTE チャンクからは回復できませんが、truecolor 画像の無効な PLTE を無視することはできます；アルファチャネルを抽出するプログラムは無効な gAMA を無視できますが、複数の tRNS があることを致命的なエラーと見なすかもしれません。構文エラー以外の異常な状況は次のように扱うべきです：

1. 未知の補助チャンクに遭遇することは決してエラーではありません。そのチャンクは単に無視できます。
2. 未知のクリティカルチャンクに遭遇することは、データストリームから画像を抽出しようとする任意のデコーダにとって致命的な状態です。クリティカルチャンクを無視したデコーダは、エンコーダが意図した画像を抽出したかどうかを判断できなくなります。
3. PNG シグネチャ不一致、CRC 不一致、あるいは予期しないストリーム終端はデータストリームの破損を示し、致命的なエラーと見なすことができます。デコーダはデータストリームから何かを救出しようとすることもできますが、損傷の程度は不明です。

致命的な状態が発生した場合、デコーダは直ちに失敗し、適切であればユーザにエラーを通知し、オプションとしてすでにユーザに表示されている image data の表示を継続すべきです（つまり「優雅に失敗」する）。アプリケーション全体が終了する必要はありません。

致命的でないエラーが発生した場合、デコーダは適切であればユーザに警告を出し、エラーから回復して通常の処理を継続すべきです。

インデックスカラ PNG をデコードする際に範囲外のインデックスが見つかった場合、その処理は歴史的にデコーダ間でばらつきがありました。ピクセルを不透明の黒として表示する は一般的な回復手段であり、本仕様ではこれを必須とします。古い実装では挙動が異なるため、この振る舞いをエンコーダが前提とすることはできません。

CRC を計算しないデコーダは、明らかな構文エラーを破損の兆候と解釈すべきです（13.2 Error checking も参照）。

圧縮チャンク（IDAT, zTXt, iTXt, iCCP）のエラーはバッファオーバーランにつながる可能性があります。deflate の伸長器を実装する者はこの可能性に備えるべきです。

APNG はデータストリームの全体が読み込まれる前にフレームを逐次表示できるように設計されています。したがって一部のエラーはアニメーションの途中まで検出されない可能性があります。いかなるエラーに遭遇した場合でも、デコーダは以後のすべてのフレームを破棄してアニメーションを停止し、静止画像の表示に戻ることを強く推奨します。アニメーションが開始する前にエラーを検出したデコーダは静止画像を表示すべきです。必要に応じてエラーメッセージをユーザに表示してもよいでしょう。

デコーダは順序が乱れた APNG チャンクをエラーとして扱わなければなりません。APNG 対応の PNG editors はシーケンス番号を用いて正しい順序に復元すべきです。

PNG のエラー処理方針は 13.1 Error handling に記述されています。

未知のチャンク型は、それがクリティカルチャンクでない限りエラーとして扱ってはなりません。

チャンク型の妥当性は、4 バイトすべてが 41-5A および 61-7A（16 進）範囲内かどうかを確認することで判定できます；これは未認識チャンク型に対してのみ行えばよいことに注意してください。もし総データストリームサイズが（ファイルシステム情報や HTTP プロトコル等から）既知であれば、チャンク長の妥当性もチェックできます。CRC をチェックしない場合、バイトの欠落／追加や誤ったチャンク長によりデコーダが同期を失い、以後のデータをチャンクヘッダと誤解する可能性があります。

既知長のチャンク（例えば IHDR）に対しては、予期しないチャンク長をエラーとして扱うべきです。本仕様の将来の拡張では既存チャンクへ新フィールドを追加するのではなく、新しいチャンク型を追加して新情報を運ぶ設計となります。

既知チャンクのフィールドにおける予期しない値（例えば IHDR の圧縮方式フィールドでの未確認値）は検出されエラーとして扱われるべきです。ただし、予期しないフィールド値は クリティカル なチャンクでのみ致命的なエラーとして扱うことが推奨されます。補助チャンクの予期しない値は、そのチャンク全体を未知のチャンク型と同様に無視することで扱うことができます（この推奨はチャンクの CRC が検証済みであることを前提とします。CRC をチェックしないデコーダでは、予期しない値を破損したデータストリームの兆候として扱う方が安全です）。

標準的な PNG 画像は圧縮方式 0 で圧縮されなければなりません。IHDR チャンクの圧縮方式フィールドは将来の標準化や独自拡張のために用意されています。デコーダはこのバイトをチェックし、未認識のコードであればエラーを報告すべきです。詳細は 10. Compression を参照してください。

PNG データストリームは明示的に型付けされたチャンクの集合で構成されます。仕様で内容が定義されたチャンクでも、実際には任意のデータ（悪意のあるコードを含む可能性）を含むことがあり得ます。同様に IEND チャンクの後にあるデータも任意のものであり、悪意あるコードを含む場合があります。そのような悪意あるコードが PNG 画像のデコードの結果として受信側のコンピュータ上で実行されるという既知のリスクはありません。しかしながら悪意のあるアプリケーションが無害に見える画像ファイル内にコードを隠し、その後それを実行する可能性はあります。

将来のチャンク型に関連する可能性のあるセキュリティリスクは現時点で特定できません。将来の公開チャンクを定義する際にはセキュリティ問題が考慮されます。未知または未実装のチャンク型には追加のセキュリティリスクはありません。なぜならそのようなチャンクは無視されるか、最大でも別の PNG データストリームへコピーされるだけだからです。

iTXt, tEXt, zTXt チャンクはキーワードと表示用のプレーンテキストを含みます。iCCP および sPLT もキーワードを含み、表示用テキストです。デコーダがこれらのテキストを制御文字、特に ESC（エスケープ）文字をフィルタリングせずに表示すると、一部のシステムや端末で望ましくない動作や安全上の問題を引き起こす可能性があります。デコーダはこのリスクを避けるために制御文字を除去することを推奨します；詳細は 13.7 Text chunk processing を参照してください。

eXIf チャンクについては、Exif 仕様 [CIPA-DC-008] において、タグの「value offset」ポインタが実際にファイル内の有効なアドレスを指すべきという明示的な要件は含まれていません。この要件は暗黙的に示唆されるのみです（Exif IFD 構造を説明するパラグラフ 4.6.2 を参照）。いずれにせよ、デコーダは無効なポインタに遭遇する可能性に備え、それらを適切に処理するべきです。

すべてのチャンクは長さフィールドで始まるため、バッファオーバーフローを試みるような不正なチャンクに対して脆弱でないデコーダを書くのが容易になります。各チャンク末尾の CRC は偶発的な破損に対する強力な防御手段を提供します。PNG シグネチャバイトは一般的なファイル伝送エラーを早期に検出するためのものです。

CRC をチェックしないデコーダはデータ破損に晒される可能性があります。その唯一のありそうな結果は画像内のピクセル表示の誤りです。もっと悪い事態としては、IHDR チャンクの CRC をチェックせず、幅や高さフィールドが破損していると重大な問題が発生することがあります。詳細は 13.2 Error checking を参照してください。

不適切に書かれたデコーダはチャンクが極めて大きく（最大 2³¹-1 バイト）なり得ることからバッファオーバーフローの対象となるかもしれません。しかし、適切に書かれたデコーダは大きなチャンクを問題なく扱います。

一部の画像編集ツールは歴史的に、編集領域のアルファチャネルをゼロに設定するだけで実際の画像データを削除していないまま機密情報を抹消したつもりになることがありました。そのような画像を見た目だけで信頼すると、実際の画像データが容易に復元され得るためプライバシーリスクがあります。

同様に、一部の画像編集ツールは IHDR の幅と高さを書き換えることで切り取り（clipping）を行い、画像データ自体を再エンコードしないため、新しい幅と高さの外側に元のデータが残り復元される可能性があります。

eXIf チャンクを含む画像は、自動的に付加されるデータ（例えば写真の GPS 座標）を含んでいることがあり、ユーザが PNG にそのようなデータが含まれていることに気づいていないとプライバシー上のリスクになり得ます。（Exif を含む他の画像形式、例えば JPEG/JFIF も同様のリスクがあります。）

デコーダはチャンク型を単純な 4 バイトのリテラル比較で認識しなければなりません；チャンク型に対して大文字小文字変換を行うのは誤りです。補助ビットが 1 の未知チャンクに遭遇したデコーダは安全にそのチャンクを無視して画像表示を続行できます。補助ビットが 0（クリティカル）である未知チャンクに遭遇した画像抽出を試みるデコーダは、その画像に安全に解釈できない情報が含まれていることをユーザに示すべきです。

デコーダは未知のチャンク型の性質を指定されたビットを数値的にテストすることで検証すべきです。文字が大文字か小文字かをテストするのは非効率であり、ロケール特有の大文字小文字定義を用いた場合に誤りとなることがあります。

予約ビットが 1 に設定されている場合はエラーを報告すべきではありません。将来の PNG 仕様でこのビットに意味が定義される可能性があるためです。このビットがセットされたチャンクは他の未知チャンク型と同様に扱えば十分です。

チャンク型のプライベートビットは機能的な意味を持たず、W3C によって定義されたチャンクと個別定義のチャンクの衝突を避けるために使用されるものであるため、デコーダはこれをテストする必要はありません。

すべての補助チャンクは任意です；デコーダはそれらを無視できます。しかし、適切かつ可能であればデコーダはこれらのチャンクを解釈することが奨励されます。

非正方ピクセルは表現可能です（11.3.4.3 pHYs Physical pixel dimensions を参照）が、ビューアがそれを考慮する義務はありません；ビューアは任意の PNG データストリームをピクセルが正方形であるかのように提示できます。

表示のピクセルアスペクト比が PNG データストリームで定義された物理ピクセル寸法のアスペクト比と異なる場合、ビューアは適切な表示のために画像をリスケールすることが強く推奨されます。

pHYs チャンクの unit specifier が 0（単位不明）の場合、デコーダの挙動は 2 つの pixels-per-unit 値の比に依存してもよいですが、その大きさには依存すべきではありません。例えば pHYs が (ppuX, ppuY, unit) = (2, 1, 0) を含む場合、それは (1000, 500, 0) を含むものと同等です；どちらも画像のピクセルが幅の 2 倍の高さを持つことを示す有効な指示です。

ビューアが画像と表示装置のピクセルアスペクト比の違いを扱う一つの合理的な方法は、画像を水平方向か垂直方向のどちらか一方に拡大することです。スケール係数は次の浮動小数点計算で得られるかもしれません：

image_ratio = pHYs_ppuY / pHYs_ppuX
display_ratio = display_ppuY / display_ppuX
scale_factor_X = max(1.0, image_ratio/display_ratio)
scale_factor_Y = max(1.0, display_ratio/image_ratio)

面積維持など他の方法も合理的であり、pHYs チャンクを無視することも許容されるため、作成者はすべてのビューアがこのスケーリング方法を使うと仮定すべきではありません。

ピクセルアスペクト比の補正に加えて、ビューアは水平方向および垂直方向の追加スケーリングを行う理由があるかもしれません。例えばディスプレイに収まらないほど大きな画像を縮小したり、高解像度プリンタへ送る際に表示と同じ物理寸法に見えるよう拡大する場合などです。

現実的であれば、PNG デコーダはデータストリーム内で見つかったすべての iTXt、tEXt、および zTXt チャンクをユーザに表示する手段を持つべきです。デコーダが特定のテキストキーワードを認識しなくても、ユーザはそれを理解できるかもしれません。

tEXt および zTXt を処理する際、デコーダは許可されていない文字に遭遇する可能性があります。一部は安全に表示できます（例えば TAB, FF, CR、16 進で 09, 0C, 0D）が、特に ESC 文字（16 進 1B）は表示ハードウェアやソフトウェアに予期せぬ動作を引き起こす可能性があり安全上の危険をもたらすかもしれません。デコーダは tEXt または zTXt で見つかった非 Latin-1 文字（改行および場合によっては TAB を除く）を直接表示しようとすべきではありません。代わりにそれらを無視するか、"\nnn" のような可視表記で表示するべきです。詳細は 13.3 Security considerations を参照してください。

iTXt チャンクを処理する際、デコーダは UTF-8 decode（Encoding Standard）に従うべきです。

エンコーダは改行を linefeed（16 進 0A）で表すことが推奨されていますが、デコーダはこれに依存すべきではありません。CR, LF, CR-LF といった一般的な改行の組合せすべてを認識し、それぞれを単一の改行として表示するのが最良です。TAB は 8 の倍数の列に整列するために適切な数のスペースに展開できます。

非 Latin-1 のレガシー文字エンコーディングを持つシステム上で動作するデコーダは、Latin-1 文字が正しく表示されるよう文字コードをリマップすべきです。サポートされない文字はシステムに適した置換文字（例えば U+FFFD REPLACEMENT CHARACTER、U+003F QUESTION MARK、または U+001A SUB）に置き換えるか、"\nn" のような可視表記にマップするべきです。文字はデコードシステム上で印字可能な文字である場合にのみ表示されるべきです。一部のバイト値はデコードシステム上で制御文字として解釈され得るため、そのようなシステム上で動作するデコーダはこれらの制御文字を表示しないべきです（セキュリティのため）。

デコーダは、エンコーダが 79 文字を超える行を作らないよう推奨されているにもかかわらず、改行間に任意の数の印字文字を含むテキストチャンクを表示できる用意をしておくべきです。

本仕様で用いる圧縮技術は、伸長を開始する前に圧縮データストリーム全体が利用可能であることを要求しません。したがって伸長済みデータ全体が得られる前に表示を開始できます。将来の本仕様のバージョンで用いられる一般的な圧縮手法がこの性質を失う可能性は極めて低いと考えられます。

IDAT チャンク境界は意味的な重要性を持たず、圧縮データストリームの任意の点で現れ得ることを強調することが重要です。image data（例えばスキャンライン境界）と deflate ブロック境界や IDAT チャンク境界との間に必須の相関はありません。完全な image data は、複数の zlib データストリームとして表現され、それがいくつかの IDAT チャンクに格納されます；デコーダがこれ以上のものを仮定するのは誤りです。エンコーダの実装によってはこれらの構造が関連づけられる場合もありますが、デコーダはそれに依存してはなりません。

フィルタの効果を逆にするために、デコーダは同じ行の前のピクセル、前行の現在ピクセルのすぐ上のピクセル、および前行の左隣のピクセルの復号済み値を使う必要がある場合があります。これはデコーダが常に少なくとも 1 行分の image data を保持しておく必要があることを意味します。いくつかのフィルタタイプは前行を参照しないものもありますが、次の行がその参照を使うかもしれないため、デコーダは各スキャンラインをデコードするごとに格納する必要があります。詳細は 7.3 Filtering を参照してください。

デコーダはインターレースされた画像を読み取ることが要求されます。参照画像が 5 列未満または 5 行未満の場合、いくつかのパスは空になります。エンコーダとデコーダはこのケースを正しく扱わなければなりません。特に、フィルタタイプバイトは非空のスキャンラインにのみ関連付けられており、空の縮約画像にはフィルタタイプバイトは存在しません。

低速伝送リンク上で画像を受信する場合、ビューアはインターレース画像を段階的に表示することで知覚的性能を改善できます。これは各縮約画像を受信するごとに、これまで受信したデータに基づく完全画像の近似を表示することを意味します。受信した各ピクセルをまだ伝送されていない右下方向の位置を覆う長方形に拡大して塗りつぶすという単純で見栄えの良い効果が得られます。この処理は以下の ISO C コードで説明できます [ISO_9899]：

/*
    variables declared and initialized elsewhere in the code:
        height, width
    functions or macros defined elsewhere in the code:
        visit(), min()
 */

int starting_row[7]  = { 0, 0, 4, 0, 2, 0, 1 };
int starting_col[7]  = { 0, 4, 0, 2, 0, 1, 0 };
int row_increment[7] = { 8, 8, 8, 4, 4, 2, 2 };
int col_increment[7] = { 8, 8, 4, 4, 2, 2, 1 };
int block_height[7]  = { 8, 8, 4, 4, 2, 2, 1 };
int block_width[7]   = { 8, 4, 4, 2, 2, 1, 1 };

int pass;
long row, col;

pass = 0;
while (pass < 7)
{
    row = starting_row[pass];
    while (row < height)
    {
        col = starting_col[pass];
        while (col < width)
        {
            visit(row, col,
                  min(block_height[pass], height - row),
                  min(block_width[pass], width - col));
            col = col + col_increment[pass];
        }
        row = row + row_increment[pass];
    }
    pass = pass + 1;
}

関数 visit(row,column,height,width) は次に送られてくるピクセルを取得し、その色で指定された高さと幅の長方形（左上隅が指定の行と列）を塗ります。row と column は左上隅を 0,0 とした測度であることに注意してください。

ビューアが受信した画像を背景画像と合成している場合、受信したピクセル位置だけを描画する方が都合がよいかもしれません（visit() は指定の行と列のピクセルのみを設定し、長方形全体を塗るわけではありません）。これにより新しい画像が徐々に古い画像を置き換える「フェードイン」効果が得られます。この方法の利点は各ピクセルが置き換えられるたびに適切なアルファまたは透過処理が行えることです。上で説明したように長方形を塗る方法は、後に受信されるピクセルが完全または部分的に透明である場合に必要となる背景画像のピクセルを上書きしてしまい得ます。これは背景画像がオフスクリーンに保存されていない場合にのみ問題になります。

PNG のユニバーサルな交換性という目標を達成するために、デコーダはすべての種類の PNG イメージを受け入れなければなりません：indexed-color、 truecolor、および greyscale。indexed-color 表示ハードウェア上で動作するビューアは、表示のために truecolor イメージを indexed-color に縮約できる必要があります。この処理は「カラ量子化（color quantization）」と呼ばれます。

カラ量子化の簡単で高速な方法は、イメージを固定パレットへ縮約することです。均一な色間隔のパレット（いわゆる「カラキューブ」）はピクセルごとの計算を最小にするために通常用いられます。写真のような画像の場合、滑らかなグラデーションに不自然な段差が生じないようにディザリングが推奨されますが、ディザリングは雑味（graininess）を導入するため好ましくない場合もあります。

レンダリング品質は、画像固有に選ばれたパレットを使うことで大幅に改善され得ます。というのも、カラキューブには特定の画像で使われないエントリが多く含まれることが一般的だからです。この方法では、まずパレットを選ぶ作業、次に個々のピクセルを最も近い色にマップする作業が必要になり、作業量が増えます。PNG ではエンコーダが推奨パレットを提供できるようになっていますが、すべてのエンコーダがそれを行うわけではなく、提供された推奨パレットが不適切である可能性もあります（色数が多すぎる／少なすぎるなど）。したがって、高品質なビューアはパレット選択ルーチンを持っている必要があります。個々のピクセルを十分な速度でパレットエントリへマップするためには、大きなルックアップテーブルが通常もっとも実行可能な方法です。

カラ量子化の実装は多数存在します。PNG のサンプル実装である libpng (http://www.libpng.org/pub/png/libpng.html) にはこの目的のためのコードが含まれています。

デコーダは表示のために PNG データをより低いサンプル深度（データ精度）へ縮小したい場合があります。例えば、16 ビットデータは現在のほとんどの表示ハードウェアで利用するために 8 ビット深度へ縮小する必要があります。8 ビットから 5 ビットへの縮小も一般的です。

最も正確なスケーリングは次の線形式で得られます

output = floor((input * MAXOUTSAMPLE / MAXINSAMPLE) + 0.5)

ここで

MAXINSAMPLE = (2sampledepth)-1
MAXOUTSAMPLE = (2desired_sampledepth)-1

わずかに精度が落ちる変換として、単に (sampledepth - desired_sampledepth) ビットだけ右シフトする方法があります。例えば 16 ビットサンプルを 8 ビットに縮小するには低位バイトを破棄できます。多くの状況ではシフト法は表示目的には十分な精度を持ち、速度面で有利です。（ただしもし gamma 補正が行われる場合、サンプルの再スケーリングは gamma 補正のルックアップテーブルへ統合でき、これは 13.13 Decoder gamma handling に示されています。）

デコーダがサンプルを拡大する必要がある場合（例えば frame buffer のサンプル深度が PNG イメージより大きい場合）、12.4 Sample depth scaling に記述されたように線形スケーリングまたは左ビット複製（left-bit-replication）を使用するべきです。

sBIT チャンクが存在する場合、参照用の image data は sBIT で指定されたサンプル深度へ右シフトして復元できます。線形スケーリングは必ずしも元のデータを再現しないことに注意してください。なぜならエンコーダが上向きスケーリングに線形スケーリングを使ったと要求されているわけではないからです。しかしエンコーダは高位ビットを保つ方法を用いることが要求されているため、右シフトは常に機能します。これはシフト法が線形スケーリングより正確であると言える唯一のケースです。デコーダは sBIT を無視してもかまいません；格納された画像は IHDR チャンクで示されたサンプル深度の有効な PNG データストリームです。しかし sBIT を使って表示用にスケーリングする前の元のサンプルを回復することは、sBIT を無視するよりもより正確な表示をもたらすことが多いです。

tRNS チャンク値とピクセル値を比較して透過ピクセルを検出する場合、比較は正確に行われなければなりません。したがって、透過ピクセル検出はサンプル精度を下げる前に行わなければなりません。

ガンマに関する簡単な導入は C. Gamma and chromaticity を参照してください。

フルカラーマネジメント対応のビューアは、ここで述べるよりも高度な計算を行うでしょう。

正しいトーン再現を行うために、表示プログラムはサンプルと表示出力との関係、および表示システムの transfer function を考慮する必要があります。これは次のように計算することで行えます：

sample = integer_sample / (2sampledepth - 1.0)
display_output = sample1.0/gamma
display_input = inverse_display_transfer(display_output)
framebuf_sample = floor((display_input * MAX_FRAMEBUF_SAMPLE)+0.5)

ここで integer_sample はデータストリームからのサンプル値、framebuf_sample は frame buffer に書き込む値、MAX_FRAMEBUF_SAMPLE はフレームバッファサンプルの最大値（8 ビットなら 255、5 ビットなら 31 など）です。第一行は整数サンプルを 0.0〜1.0 範囲の正規化された浮動小数点値へ変換します。第二行は望ましい表示出力強度に比例する値へ変換し、第三行は表示システムの transfer function を考慮し、第四行は整数のフレームバッファサンプルへ変換します。0 を正のべき乗に上げると 0 になります。

第二行と第三行の間にステップを挿入して、実際の視聴条件と参照視聴条件の差を補正することもできます。しかしこの補正は veiling glare、black mapping、色の見え方モデルなどを考慮する必要があり、べき関数だけでは良く近似できません。ここではそのような計算は記述しません。視聴条件を無視しても通常誤差は小さいです。

表示の transfer function は通常、指数 display_exponent によるべき関数で近似できます。その場合、第二行と第三行は次のようにまとめられます：

display_input = sample1.0/(gamma * display_exponent) = sampledecoding_exponent

これによりべき乗計算を 1 回だけ行えばよくなります。カラー画像ではこの計算を R, G, B 各々について行います。

gAMA チャンクから gamma value を直接取得できます。あるいはアプリケーションでユーザが表示外観を調整できるようにして gamma value に影響を与えられるようにすることも可能です。例えば、ユーザはデフォルト 1.0 のパラメータ user_exponent を手動で設定し、アプリケーションは次のように設定できます：

gamma = gamma_from_file / user_exponent
decoding_exponent = 1.0 / (gamma * display_exponent)
   = user_exponent / (gamma_from_file * display_exponent)

ユーザは中間階調を暗くしたいときは user_exponent を 1 より大きく、明るくしたいときは 1 より小さく設定します。

gAMA チャンクにゼロが入っていると意味を成しませんが、誤って出現することがあります。デコーダはそれを無視し、エディタはそれを破棄してユーザに警告してもよいでしょう。

すべてのピクセルごとに超越関数を計算する必要はありません。代わりに、各可能なサンプル値に対して正しい出力値を与えるルックアップテーブルを事前に作成できます。これは 8 ビット精度なら各イメージにつき 256 回の計算だけで済みます。インデックスカラー画像では、パレットの一度だけの補正で十分です（画像が透過を使っていて非一様な背景に表示する場合を除く）。

浮動小数点計算が使えない場合でも、gamma 補正テーブルは整数演算と事前計算した対数表を使って作成できます。例コードは [PNG-EXTENSIONS] にあります。

入力イメージの gamma value が不明な場合（gAMA、sRGB、および iCCP がすべてない場合）、単体の画像ビューアは妥当と思われるデフォルトの gamma value を選ぶべきですが、結果が暗すぎる／明るすぎる場合にはユーザが新しい値を選べるようにすべきです。デフォルトの gamma value は、画像がインターネット由来かローカル由来かなど他の情報に依存して決めてもよいでしょう。HTML のような文書形式や SVG のようなベクタ形式のビューアは、未タグの PNG 画像を他の未タグ画像と同様に扱うべきです。

実際には、どの表示指数を用いるべきかを決めるのはしばしば難しいです。システムに組み込みの gamma 補正がない場合、表示指数は主に CRT によって決まります。特定の CRT の詳細な較正測定がない限り、表示指数 2.2 を用いるべきです。

多くの現代の frame buffers には gamma 補正を実行するためのルックアップテーブルがあり、これらのシステムでは表示指数はそのルックアップテーブルと CRT の複合指数であるべきです。ビューア内からルックアップテーブルの内容を取得できない場合、ユーザに表示システムの指数値を入力してもらう必要があるかもしれません。残念ながら、異なるメーカーはルックアップテーブルの指定方法が異なるため、システムの gamma value の解釈はシステム依存になります。

実際の表示器の応答は単一の数値（表示指数）で表せるよりも複雑です。もしモニタの電圧入力に対する光出力の実測値が利用可能なら、上記の第三・第四行はこれらの実測値を参照することで置き換えられ、望ましい明るさに最も近い実際のフレームバッファ値を求めることができます。

色に関する参照は C. Gamma and chromaticity を参照してください。

多くの場合、PNG データストリーム内の image data はデバイス依存の RGB 値として扱われ、（適切な gamma 補正を除いて）変更せずに表示されます。これは最速の表示方法ですが、ビューアが元の画像の作成者とまったく同じ表示ハードウェアを用いない限り、特に暗色やほぼ中立の色において色は作成者が見たものと完全には一致しません。cHRM チャンクは、単なる gamma 補正よりも緻密な色合わせを可能にする情報を提供します。

cHRM データは image data を RGB から XYZ へ変換し、さらに CIE LAB のような知覚的に線形な色空間へ変換するために使えます。色を CIE LAB 空間で分割すれば最適パレットを生成できます。というのも CIE LAB における 2 色間の幾何学的距離は、人間の見た目での差異と強く相関するからです（RGB や XYZ 空間とは異なります）。得られたパレットを再び RGB へ戻して表示に用いるか、PLTE チャンクへ書き込むことができます。

画像処理アプリケーションの一部として動作するデコーダは、解析のために image data を CIE LAB 空間へ変換することもあるでしょう。

色忠実度が重要な用途（プロダクトデザイン、科学的可視化、医療、建築、広告など）では、PNG デコーダはソース RGB から表示に用いるモニタの display RGB 空間への変換を行えます。これはソース RGB → XYZ の行列と XYZ → 表示 RGB の行列を計算し、それらを合成して全体の変換を得ることを含みます。PNG デコーダはガモットマッピングを実装する責任があります。

プラットフォームにカラーマネジメントシステム（CMS）が備わっている場合、デコーダは image data、gAMA、および cHRM の値を CMS に渡して表示やさらなる処理を行わせることができます。

カラー印刷機能を提供する PNG デコーダは、Level 2 PostScript の機能を使ってキャリブレートされた RGB 空間や XYZ のようなデバイス非依存色空間で image data を指定できます。これは単純な RGB→CMYK 変換よりも良い色忠実度を提供します。PostScript Language Reference マニュアル [PostScript] に例が示されています。そのようなデコーダはソース RGB（cHRM に指定）とターゲットプリンタ間のガモットマッピングを実装する責任があり、PostScript インタプリタが所望の色を生成します。

PNG デコーダは cHRM データを使用して、カラー画像の正確なグレースケール表現を計算できます。RGB からグレイへの変換は単に XYZ の Y（輝度）成分を計算することであり、これは R, G, B の重み付き和です。重みはモニタの種類、すなわち cHRM チャンクの値に依存します。PNG デコーダは cHRM を持たないデータストリームに対してこれを行いたい場合があります。その場合の妥当なデフォルトは CCIR 709 原色です [ITU-R-BT.709]。オリジナルの NTSC 原色は、PNG 画像が本当にそのようなモニタ用に色合わせされていない限り 使用すべきではありません。

bKGD チャンクで指定された背景色は、通常画像周辺の未使用スクリーンスペースや、画像内の透過ピクセルを塗りつぶすために使用されます。（したがって、画像が透過を使用していない場合でも bKGD は有効かつ有用です。）もし bKGD チャンクが存在しない場合、ビューアは適切な背景色を決定する必要があります。他に情報がない場合、8 ビット sRGB カラースペースで 153 のような中間灰色が妥当な選択です。透明な黒や白のテキストや暗いドロップシャドウなどは、この背景に対して判読可能です。

特定の背景で画像を提示するビューア（ウェブブラウザなど）は bKGD を無視し、自身の好む背景色や背景画像で bKGD を上書きすべきです。

bKGD チャンクで示された背景色は、たとえそれが tRNS チャンクで示された色と一致していても、透明とは見なされません（または、indexed-color 画像の場合に tRNS が透過としてマークしているパレットインデックスに対応する場合でも同様です）。さもなければ背景の「背後に何か」を想定して合成しなければならなくなります。背景色は使用されるか無視されるかのどちらかであり、PNG イメージと他の背景の間の中間レイヤーではありません。

実際、多くの場合 bKGD と tRNS が同じ色を指定することが普通です。そうすれば透過処理を実装していないデコーダでも、部分的に透明なピクセルが存在しない限り意図した表示が得られます。

アルファチャネルは前景イメージを背景イメージに合成（composite）するために使用できます。PNG データストリームは前景画像と透過マスクを定義しますが、背景画像は定義しません。PNG デコーダはこの最も一般的なケースをサポートすることを要求されません。多くのデコーダは単一の背景色に対する合成をサポートすることが期待されます。

合成されたサンプル値を計算する式は次の通りです：

output = alpha * foreground + (1-alpha) * background

ここで alpha および入出力サンプル値は 0〜1 の分数で表されます。この計算は強度サンプル（gamma エンコードされていないサンプル）で行うべきです。カラー画像の場合、R, G, B の各サンプルについて個別に計算します。

以下のコードは、前景画像を背景画像に合成する一般的なケースを示します。背景画像の元のピクセルデータが利用可能であり、出力が表示用の frame buffer であると仮定します。他のバリエーションも可能です；コード下のコメントを参照してください。このコードは前景画像と背景画像のサンプル深度や gamma values が異なっていて、表示システムに最適化されていない場合でも動作するようにしています。実際には何も仮定せずまずチェックすべきです。

このコードは ISO C 構文で、コメント参照用に行番号を付しています。

01  int foreground[4];  /* image pixel: R, G, B, A */
02  int background[3];  /* background pixel: R, G, B */
03  int fbpix[3];       /* frame buffer pixel */
04  int fg_maxsample;   /* foreground max sample */
05  int bg_maxsample;   /* background max sample */
06  int fb_maxsample;   /* frame buffer max sample */
07  int ialpha;
08  float alpha, compalpha;
09  float gamfg, linfg, gambg, linbg, comppix, gcvideo;

    /* Get max sample values in data and frame buffer */
10  fg_maxsample = (1 << fg_sample_depth) - 1;
11  bg_maxsample = (1 << bg_sample_depth) - 1;
12  fb_maxsample = (1 << frame_buffer_sample_depth) - 1;
    /*
     * Get integer version of alpha.
     * Check for opaque and transparent special cases;
     * no compositing needed if so.
     *
     * We show the whole gamma decode/correct process in
     * floating point, but it would more likely be done
     * with lookup tables.
     */
13  ialpha = foreground[3];

14  if (ialpha == 0) {
        /*
         * Foreground image is transparent here.
         * If the background image is already in the frame
         * buffer, there is nothing to do.
         */
15      ;
16  } else if (ialpha == fg_maxsample) {
        /*
         * Copy foreground pixel to frame buffer.
         */
17      for (i = 0; i < 3; i++) {
18          gamfg = (float) foreground[i] / fg_maxsample;
19          linfg = pow(gamfg, 1.0 / fg_gamma);
20          comppix = linfg;
21          gcvideo = pow(comppix, 1.0 / display_exponent);
22          fbpix[i] = (int) (gcvideo * fb_maxsample + 0.5);
23      }
24  } else {
        /*
         * Compositing is necessary.
         * Get floating-point alpha and its complement.
         * Note: alpha is always linear; gamma does not
         * affect it.
         */
25      alpha = (float) ialpha / fg_maxsample;
26      compalpha = 1.0 - alpha;

27      for (i = 0; i < 3; i++) {
            /*
             * Convert foreground and background to floating
             * point, then undo gamma encoding.
             */
28          gamfg = (float) foreground[i] / fg_maxsample;
29          linfg = pow(gamfg, 1.0 / fg_gamma);
30          gambg = (float) background[i] / bg_maxsample;

31          linbg = pow(gambg, 1.0 / bg_gamma);
            /*
             * Composite.
             */
32          comppix = linfg * alpha + linbg * compalpha;
            /*
             * Gamma correct for display.
             * Convert to integer frame buffer pixel.
             */
33          gcvideo = pow(comppix, 1.0 / display_exponent);
34          fbpix[i] = (int) (gcvideo * fb_maxsample + 0.5);
35      }
36  }

バリエーション：

1. 出力が frame buffer ではなく別の PNG データストリームの場合、行 21, 22, 33, 34 は次のように変更されるべきです。

   /*
    * Gamma encode for storage in output datastream.
    * Convert to integer sample value.
    */
   gamout = pow(comppix, outfile_gamma);
   outpix[i] = (int) (gamout * out_maxsample + 0.5);

   また、アルファがゼロのときに背景ピクセルを処理する必要があり、ただスキップするだけではなく、行 15 は背景ピクセルを処理するために行 17-23 のコピーに置き換える必要があります。
2. 出力ファイル、前景ファイル、背景ファイルのサンプル深度がすべて同じで、かつ三者の gamma values も一致するなら、行 14-23 の非合成コードは、アルファが 1 の場合は入力から出力へピクセル値をコピーし、アルファが 0 の場合は背景を出力へコピーするだけに簡略化されます。画像内の大多数のピクセルでアルファが 0 または 1 であることが一般的であるため、これは大きな時間節約になります。ほとんどのピクセルについて gamma 計算は不要です。
3. サンプル深度と gamma values がすべて一致する場合、行 28-31 と 33-34 の gamma デコード／エンコードを省略して、行 32 を gamma エンコード済みサンプル値で直接行うことが一見魅力的に見えます。これは画像品質に大きな悪影響を与えないことがありますが、アルファ値が 0 と 1 の特殊ケースをここで扱うなら時間節約は小さいです。
4. 背景画像の元のピクセル値が利用できない場合、背景の表示で残された処理済みの frame buffer ピクセルしか残っていない場合、行 30 と 31 は次のようにフレームバッファ値から強度を抽出するコードへ置き換える必要があります：

   /*
    * Convert frame buffer value into intensity sample.
    */
   gcvideo = (float) fbpix[i] / fb_maxsample;
   linbg = pow(gcvideo, display_exponent);

   ただし丸め誤差が生じる可能性があるため、可能なら元の背景ピクセルを利用する方が望ましいです。
5. 行 18-22 はアルファが無い場合に行われるのと全く同じ gamma 計算を実行しています。もし非アルファのケースをルックアップテーブルで処理しているなら、同じルックアップテーブルをここでも使えます。行 28-31 と 33-34 も（別の）ルックアップテーブルで行えます。
6. 整数演算を用いることも可能です。その場合は十分な精度を保つために注意を払うべきです。

フルアルファチャネルを持つ PNG 画像を表示する際は、たとえ背景が単なる黒であっても画像を何かの背景に合成できることが重要です。アルファを無視すると、associated-alpha 表現から変換された PNG 画像は見た目が正しくなくなります。（もちろんアルファチャネルが別個の透明マスクである場合、アルファを無視するのは隠された部分を回復するために有用なオプションになります。）

デコーダが真の合成ロジックを実装していない場合でも、アルファ値が 0 と 1 のみを含む画像への対処は簡単です（これは greyscale や truecolor の PNG データストリームが tRNS チャンクを使う場合に暗黙的に当てはまります。indexed-color PNG データストリームの場合、tRNS が 0 と 255 以外の値を含むかどうかを簡単にチェックできます。）この単純なケースでは、透過ピクセルは背景色で置き換えられ、他のピクセルは変更されません。

もしデコーダがこれだけの透過機能しか持たない場合、フルアルファチャネルを扱うときは、すべての非ゼロアルファ値を不透明として扱うか、あるいはディザリングするべきです。いずれの方法も associated-alpha 形式から変換された画像に対してはあまり良い結果を与えませんが、何もしないよりは望ましいです。フルアルファを二値アルファへディザするのは、グレースケールを白黒へディザするのと非常に似ていますが、完全に透明なピクセルと完全に不透明なピクセルはディザによって変更されないようにするべきです。

indexed-color ハードウェア上で truecolor 画像を表示しようとするビューア、またはフレームバッファーが受け入れられるよりも大きなパレットを持つ indexed-color 画像に対しては、エンコーダが一つ以上の推奨パレットを sPLT チャンクで提供している場合があります。サイズや（場合によっては）名前に基づいてそれらの中から適切なものが見つかった場合、PNG デコーダはそのパレットを使用できます。デコーダが必要とするものとサンプル深度が異なる推奨パレットは、サンプル深度の再スケーリングで変換できます（13.12 Sample depth rescaling参照）。

背景が単色である場合、ビューアは画像と推奨パレットをその色に対して合成（composite）し、得られた画像を元に RGB パレットへ量子化するべきです。画像が透過を使用していて背景が単色でない場合、推奨パレットはほとんど役に立たないでしょう。

truecolor 画像の場合、推奨パレットは PLTE チャンクにも含められていることがあります。画像が tRNS チャンクを持ち背景が単色である場合、ビューアは望ましい背景色に合わせて推奨パレットを調整する必要があります。その方法としては、tRNS の色に最も近いパレットエントリを望ましい背景色に置き換えるか、ビューアが PLTE エントリ数より多くの色を扱えるなら背景色用のパレットエントリを追加する、などがあります。

color type 6（truecolor with alpha）の画像については、任意の PLTE チャンクは bKGD チャンクで指定された単色背景に対して画像を表示するために設計されているはずです。ビューアが異なる背景を使うつもりである場合や bKGD チャンクが存在しない場合は、そのパレットを無視するのが妥当でしょう。異なる背景で表示するために推奨パレットを使うことは可能ですが、結果はあまり良くない場合があります。

ビューアが透明な truecolor 画像を非均一な背景（単色より複雑な背景）に対して提示する場合、推奨パレットが合成（composite）された画像に最適であることはほとんど期待できません。この場合は、truecolor PNG 画像と背景画像を先に合成し、その結果画像を色量子化するのが最良です。

truecolor の PNG データストリーム内で PLTE と sPLT の両方のチャンクが現れる場合、PNG デコーダは両者が提案するパレットの中から選ぶことができますが、上述した透明性に関する違いを考慮に入れるべきです。

sPLT および hIST チャンクの周波数情報は、ビューアが PNG データストリームで使用されているパレットと同じだけの色を提供できない場合に有用です。もしビューアがほんの数色しか不足していないなら、パレットの使用頻度が最も低い色を削るだけで十分な場合が多いです。色数を大幅に減らす必要がある場合は、既存パレットのサブセットを使おうとするよりも、まったく新しい代表色を選ぶ方が良いです。これは新しい色量子化処理を行うことに相当しますが、既存のパレットとヒストグラムを入力データとして使えば、IDAT チャンク中の image data を走査する手間を省くことができます。

推奨パレットが提供されていない場合、デコーダは自前でパレットを生成できますが、そのためには IDAT チャンク内の image data を一度走査する必要があり追加のコストがかかります。代わりにデフォルトのパレット（おそらくカラキューブ）を使用することもできます。

関連項目は 12.5 Suggested palettes を参照してください。

作者は新しいチャンク型を検討する前に、本仕様や [PNG-EXTENSIONS] にある既存のチャンク型を確認することが奨励されます。PNG-EXTENSIONS にあるチャンク型は、本仕様で定義されたものよりも広くサポートされないことが予想されます。

PNG editors の例として、テキストチャンクを追加・変更するプログラムや、truecolor PNG データストリームに推奨パレットを追加するプログラムが挙げられます。一般的な画像編集ソフトは画像を読み込む際に未認識の情報を破棄するため、通常は PNG editors とは見なされません。

PNG に新しいチャンク型を追加できるようにするためには、すべてのチャンク型に対する並び順の要件について規則を確立する必要があります。さもなければ、PNG editor が未知のチャンクに遭遇したときに何をすべきか分からなくなります。

例: 仮想的な新しい補助チャンク型があって、それは PLTE が存在する場合に PLTE の後に現れることが要求されるとします。プログラムがその新チャンクを認識せずに PLTE を追加しようとすると、誤って新チャンクの後に PLTE を挿入してしまう可能性があります。このような問題は、未知チャンクをすべて破棄するように PNG editors に強制すれば防げますが、それは非常に魅力のない解決策です。代わりに、PNG は補助チャンクにこのような厳しい順序制約を持たせないことを要求します。

この種の問題を将来の拡張を許容しつつ防ぐために、PNG editors の振る舞いとチャンクの並び順に制約が課されています。safe-to-copy ビットは、修正されるデータストリーム内の未認識チャンクの取り扱いを定義します。

1. チャンクの safe-to-copy ビットが 1 の場合、そのチャンクは PNG editor がそのチャンク型を認識しているかどうかにかかわらず、修正後の PNG データストリームへコピーしてよい。
2. チャンクの safe-to-copy ビットが 0 の場合、そのチャンクは image data に依存することを示します。プログラムがクリティカルなチャンクに対して何らかの変更（追加、変更、削除、または並べ替え）を行った場合、未認識の unsafe チャンクは出力 PNG データストリームへコピーしてはなりません。（もちろん、プログラムがそのチャンクを認識していれば、適切に修正した版を出力することはできます。）
3. PNG editor が補助チャンクのみを追加・削除・変更・並べ替えた場合、未認識の補助チャンクをすべてコピーして構いません。これは補助チャンクが他の補助チャンクに依存してはならないことを意味します。
4. PNG editors は、未認識のクリティカルチャンク型に遭遇した場合に処理を中止しなければなりません。というのも、そのようなチャンクを含むデータストリームを修正しても有効なデータストリームが得られると確実に言えないからです。（単にそのチャンクを破棄するだけでは不十分で、そのチャンクが他のチャンクの解釈に未知の影響を与える可能性があるためです。）safe/unsafe 機構は補助チャンクに対して想定されています。クリティカルチャンクの safe-to-copy ビットは常に 0 になります。

チャンクの並び順を決める規則は次の通りです。

1. 未認識の unsafe-to-copy 補助チャンクをコピーする場合、PNG editor はそのチャンクを任意のクリティカルチャンクに対して相対的に移動してはなりません。同じ一対のクリティカルチャンクの間に現れる他の補助チャンクに対しては自由に位置を変更できます。（これは、編集者が未知の unsafe-to-copy チャンクを保持する場合、クリティカルチャンクを追加・削除・変更・並べ替えしてはならない、という前提により明確に定義されます。）
2. 未認識の safe-to-copy 補助チャンクをコピーする場合、PNG editor はそのチャンクを IDAT の前から後へ、または後から前へ移動してはなりません。（これは IDAT が常に存在するため明確に定義されます。）それ以外の並べ替えは許可されます。
3. 既知の補助チャンク型をコピーする場合、エディタはそのチャンク型に対して存在する特定の順序規則を守れば十分です。しかし、常に上記の一般規則を適用することもできます。

これらの規則は入力データストリームから出力データストリームへチャンクをコピーする観点で表現されていますが、データストリームをその場で修正する場合にも明白な方法で適用されます。

また 5.4 Chunk naming conventions を参照してください。

PNG editors が image data を変更しない場合、tIME チャンクを変更してはなりません。tEXt、zTXt、および iTXt チャンクの Creation Time キーワードは、ユーザ提供の時刻として使用できます。