この節はエンコーダの動作に関する要件と推奨事項を示します。PNG エンコーダは、前節で規定された形式に準拠する PNG イメージから PNG
データストリームを生成しなければなりません。ここに示す追加の推奨事項に従うことで、通常は最良の結果が得られます。
C. ガンマと色度で、
ガンマに関する問題の簡単な説明を参照してください。
完全なカラーマネジメントに対応する PNG エンコーダーは、ここで説明するものよりも高度な計算を実行し、
iCCP チャンクの使用を
選択する場合があります。画像
サンプルが sRGB 仕様 [SRGB]
に準拠していることが分かっている場合、
エンコーダーには、追加のガンマ処理を行わずに sRGB
チャンクを書き込むことが強く推奨されます。どちらの場合も、
iCCP または sRGB
チャンクを認識しない PNG デコーダーが使用できるように、適切な gAMA チャンクを生成することが
推奨されます。
PNG エンコーダーは、次の事項を決定する必要があります。
- gAMA チャンクにどの値を書き込むか。
- 提供された画像サンプルを、PNG データストリームに書き込む値へどのように変換するか。
gAMA チャンクに書き込む値は、PNG
デコーダーを
意図したとおりに動作させる値です。13.13
デコーダーのガンマ処理を参照してください。
適用する変換は、画像サンプルの性質と精度によって異なります。
サンプルが浮動小数点形式または高精度整数形式で光
強度を表す場合（コンピューターグラフィックスレンダラーから取得した場合など）、エンコーダーは、データを PNG データストリームに含める整数
値へ量子化する前に、ガンマ
符号化（指数が 1 未満のべき関数を適用すること）を
実行できます。これにより、特定のサンプル深度でのバンディングアーティファクトが減少するか、同じ視覚品質を維持しながら
より小さなサンプルを使用できます。0 から 1 の範囲の
浮動小数点値として表される強度レベルは、
次のようにデータストリームの画像サンプルへ変換できます。
integer_sample = floor((2sampledepth-1) * intensityencoding_exponent + 0.5)
式内の intensity が目的の出力強度である場合、符号化指数は、
gAMA チャンクで
使用するガンマ値です。
PNG エンコーダーが利用できる強度が元のシーンの強度である場合、別の変換が
必要になることがあります。
表示画像に元のソース
画像よりも高いコントラストを持たせることが必要な場合があります。これは、
元のシーンから表示出力までのエンドツーエンドの伝達関数の指数が 1 より大きいことに相当します。この
場合は、次のようになります。
gamma = encoding_exponent/end_to_end_exponent
元の画像が取り込まれた、または計算された条件で
このようなコントラスト変更が妥当かどうか分からない場合は、
表示強度が元のシーンの
強度に比例すると想定できます。すなわち、
エンドツーエンド指数は 1 であるため、次のようになります。
gamma = encoding_exponent
画像をデータストリームにのみ書き込む場合、エンコーダーは符号化指数を自由に選択できます。
gAMA チャンク内のガンマ値が
1/2.2 になる値を選択することは、多くの場合妥当です。
これは、一般的なビデオモニターに表示する PNG デコーダーの処理を最小限に抑えられるためです。
一部の画像レンダラーは、画像を PNG データストリームに書き込むと同時に画面上に表示する場合があります。
表示されるピクセルは、
使用中の表示システムおよび観察条件に合わせてガンマ補正し、ユーザーが意図されたシーンを
適切に表現したものを見られるようにする必要があります。
レンダラーが、データストリーム用の独立したガンマ
符号化ステップを省略して、表示されたサンプル値を PNG データストリームに書き込む場合、レンダラーは
表示システムの伝達関数を
べき関数で近似し、その指数の逆数を gAMA チャンクに書き込む必要があります。これにより、
PNG デコーダーは、レンダリング時に作成者の画面に表示されたものを再現できます。
ただし、レンダラーが表示装置に適した表示ピクセルを計算し、
データの保存と転送のために別個のガンマ符号化を
実行し、画像の将来の用途により適した値を gAMA チャンクに
設定することも同様に妥当です。
コンピューターグラフィックスレンダラーは、多くの場合ガンマ符号化を実行せず、代わりにサンプル
値をシーンの光強度に直接比例させます。PNG エンコーダーが、すでに整数値へ量子化されたサンプル値を受け取る場合、
それらにガンマ符号化を行っても意味はありません。さらに情報が失われるだけだからです。エンコーダーは、
サンプル値をそのまま PNG データストリームに書き込む必要があります。これは、
gAMA チャンクに 1.0 のガンマ値を含める必要があることを意味しません。これは、
シーンの強度から表示出力の強度までの意図されたエンドツーエンドの伝達関数が
必ずしも線形ではないためです。ただし、意図されたガンマ値は、
おそらく 1.0 から大きく離れてはいません。レンダリングされるシーンが昼光のシーンか
屋内のシーンかなどによって異なる場合があります。
サンプル値がハードウェアから直接取得された場合、正しい gAMA 値は、
原則として、ハードウェアの伝達関数と
シーンの照明条件から推測できます。ビデオデジタイザー（「フレームグラバー」）の場合、
sRGB
仕様は最新のビデオ規格との互換性を持つよう設計されているため、サンプルはおそらく sRGB 色空間にあります。イメージスキャナーは、それほど
予測可能ではありません。CCD センサー自体は線形であるため、その出力
サンプルは入力光強度に比例している場合があります。または、スキャナーのハードウェアが、
後続の印刷におけるドットゲインを補正するよう設計されたべき関数（指数は約 0.57）をすでに
適用している場合や、
モニター上に表示するためにサンプルを補正している場合があります。特定のスキャナーの特性を判断するには、
スキャナーのマニュアルを参照するか、
較正済みターゲットをスキャンする必要がある場合があります。
ガンマは
サンプルと目的の表示出力との関係を表すものであり、スキャナー入力との関係を表すものではないことに注意する必要があります。
データストリーム形式コンバーターは通常、提供された画像を異なるガンマへ変換しようとすべきではありません。
データは
変換せずに PNG データストリームへ格納し、可能であれば、ソースデータストリーム内の
情報からガンマ値を
推測する必要があります。データストリーム変換時にガンマを変更すると、表現される
強度レベルの集合が再量子化され、ほとんど利点がないまま、さらに丸め誤差が生じます。ほとんどの場合、
入力ファイルから出力ファイルへサンプル値をそのまま
コピーする方が適切です。
ソースデータストリームが画像のガンマ特性を記述している場合、データストリームコンバーターには、
gAMA チャンクを書き込むことが強く推奨されます。一部のデータストリーム形式は、
表示指数
（画像サンプルを表示出力へマッピングする関数の指数であり、その逆方向ではない）を指定します。ソース
ファイルのガンマ値が 1.0 より大きい場合、それはおそらく表示
指数であり、この値の逆数を PNG のガンマ値に使用する必要があります。ソースファイル形式が、画像サンプルと
表示出力以外の量との関係を記録している場合、PNG のガンマ値の推測は、これよりも複雑になります。
PNG エンコーダーまたはデータストリームコンバーターが、
ある表示システムを使用して画像が十分に表示されたことを認識しており、その
伝達関数を
指数 display_exponent のべき関数で近似できる場合、その画像には
次のガンマ値を持つものとしてマークできます。
gamma = 1/display_exponent
チャンクを省略して PNG デコーダーにおおよそのガンマ値を推測させるよりも、ほぼ
正しい値を持つ gAMA チャンクを書き込む方が適切です。PNG
エンコーダーが
ガンマ値を推測できない場合は、gAMA
チャンクを省略する方が望ましいです。推測が必要な場合は、
PNG デコーダーに委ねる必要があります。
ガンマは、
アルファサンプルには適用されません。アルファは常に線形に表現されます。
13.13 デコーダーのガンマ
処理も参照してください。
色に関する参考は C. Gamma and
chromaticity を参照してください。
フルカラーマネジメント対応の PNG エンコーダは、ここで述べるより高度な計算を行い、iCCP
チャンクを使用することを選ぶかもしれません。もしイメージサンプルが sRGB 仕様に準拠すると分かっているなら、PNG エンコーダは sRGB チャンクを使用することが強く推奨されます。
ソースの表示原色の色度を決定できる、または画像の起源や実行ハードウェアに基づいて強い推測ができる場合、エンコーダは cHRM
チャンクを出力することが強く推奨されます。もしそれを行うなら、gAMA チャンクも併せて書き込むべきです；デコーダは cHRM だけではあまり利用できません。
原色や ホワイトポイント に関してはいくつかの推奨や標準があり、技術に結びつくものもあります。たとえば CCIR 709
[ITU-R-BT.709]
や SMPTE-C [SMPTE-170M]
などです。
考慮すべきケースは次の三つです：
- エンコーダが生成システムの一部である場合；
- ソース画像がカメラやスキャナでキャプチャされた場合；
- PNG データストリームが他の形式から変換によって生成された場合。
手描きやデジタル編集された画像の場合、制作時にどのモニタで表示していたかを特定する必要があります。多くの画像編集プログラムは使用中のモニタ種別を指定でき、内部でデバイス非依存空間を使っていることが多いです。そのようなプログラムは有効な
cHRM および gAMA
チャンクを書き込むのに十分な情報を持っており、自動的にそれらを書き込むことが強く推奨されます。
エンコーダがフルスペクトルレンダリングを行うコンピュータレンダラの一部としてコンパイルされている場合、内部のデバイス非依存色空間から RGB へ変換するために使用したモニタ値を cHRM チャンクに書くべきです。選択した RGB デバイスのガモット外の色はガモット内にマップされるべきです；PNG はガモット外の色を格納しません。
もしコンピュータレンダラがデバイス依存の RGB 空間で直接計算を行うなら、シーン記述とレンダリングパラメータが特定のモニタに合わせて調整されていない限り cHRM チャンクは書くべきではありません。その場合は、そのモニタのデータを使って cHRM チャンクを構築すべきです。
一部のイメージ形式はキャリブレーション情報を格納しており、それを使って cHRM チャンクを埋めることができます。たとえば TIFF
6.0 [TIFF-6.0] はオプションでキャリブレーション情報を持ち、存在するなら cHRM チャンクの構築に使うべきです。
最近の映像機器で作成された映像は、おそらく CCIR 709 の原色と D65 白色点 [ITU-R-BT.709]
を使用しており、これらは表 29に示されています。
Table 29
CCIR 709 原色と D65 ホワイトポイント
| |
R |
G |
B |
White |
| x |
0.640 |
0.300 |
0.150 |
0.3127 |
| y |
0.330 |
0.600 |
0.060 |
0.3290 |
古くから広く使われているビデオ標準の一つに SMPTE-C [SMPTE-170M]
があり、これは Table 30 に示されています。
Table 30
SMPTE-C ビデオ標準
| |
R |
G |
B |
White |
| x |
0.630 |
0.310 |
0.155 |
0.3127 |
| y |
0.340 |
0.595 |
0.070 |
0.3290 |
データストリーム形式コンバーターが、提供された画像を異なる
RGB 色空間へ変換しようとすることは推奨されません。
データは変換せずに PNG データストリームへ格納し、ソースの
原色の色度が既知の場合は記録する必要があります。データストリーム変換時の色空間変換は、
色域の不一致と丸め誤差が生じるため
適切ではありません。ガンマ変換の場合と同様に、データを
可逆的に格納し、画像が最終的に表示されるときに多くても
1 回だけ変換を行う方が適切です。
13.14 デコーダーのカラー
処理を参照してください。
アルファチャネルは、透明な部分を一時的に隠すマスクとして考えることも、非矩形イメージを構築する手段と考えることもできます。前者の場合、完全に透明なピクセルの色値は将来の利用のために保持するべきです。後者の場合、透明ピクセルは有用なデータを持たず、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
（2sampledepth-1）です。
線形スケーリング方法に近い近似値は、「左端ビット複製」によって得られます。これは、有効なビットを
最上位ビットから始まるようにシフトし、最上位のビットを空きビットに繰り返す方法です。この
方法は、多くの場合、線形スケーリングよりも高速に
計算できます。
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
|=======| |===|
| 空きビットを埋めるために左端ビットを反復
|
元のビット
これは、線形方程式で計算された値と一致します。左端ビット複製では通常、線形
スケーリングと同じ
値が得られ、その差が 1 を超えることはありません。
入力値を単純に左シフトし、下位
ビットをゼロで埋める方法では、明らかに精度の低い近似値しか得られません。この方式では、すべてのビットが 1 の
最大値が生成されないため、白を正確に再現できません。その結果、
画像がわずかに暗くなります。この方法は通常推奨されませんが、
特に 8 ビットを超えるサンプル深度を扱う場合には、圧縮率を
改善する効果があります。高いサンプル深度では、
ゼロ埋めスケーリングによって生じる相対誤差が小さいため、一部のエンコーダーはこの方法を使用する場合があります。ただし、アルファチャンネルデータにはゼロ埋めを
使用してはなりません。多くのデコーダーが、すべてゼロおよびすべて
1 のアルファ値を特殊な
ケースとして扱うためです。スケーリングされたデータで、これら両方の値を正確に表現することが重要です。
エンコーダーが sBIT チャンクを書き込む場合、
保存されるサンプルの上位ビットが元のデータと一致するように
スケーリングする必要があります。すなわち、sBIT チャンクがサンプル深度 S を指定する場合、保存される
データの上位 S ビットは、元の
S ビットのデータ値と一致しなければなりません。これにより、デコーダーは右シフトして元のデータを復元できます。追加された
下位ビットには
制約がありません。上述したすべてのスケーリング方法が、この制約を満たします。
ソースの画像データを拡大する場合、すべての
サンプルで下位ビットを一貫して埋めることが推奨されます。すなわち、同じソース値からは、どのピクセル位置でも同じサンプル値が生成される必要があります。
これにより、異なるサンプル値の数が減少し、
圧縮率が向上します。これは必須要件ではないため、
一部のエンコーダーは
この方法に従わない場合があります。たとえば、代わりに下位ビットをディザリングして、ファイルサイズが増加する代わりに
表示画像の品質を
向上させることがあります。
一部の用途では、元のソースデータの範囲が 2 のべき乗でない場合があります。線形
スケーリング方程式は、この
場合にも機能しますが、シフト方法は機能しません。このような画像には sBIT
チャンクを書き込まないことが推奨されます。これは、sBIT が、元のデータ範囲が
正確に 0..2S-1 であったことを示唆するためです。
推奨パレットは、任意の PNG データストリームでは sPLT チャンクとして、
またはトゥルーカラー PNG データストリームでは PLTE
チャンクとして現れることがあります。いずれの場合も、
推奨パレットは
画像データの不可欠な部分ではありませんが、
インデックスカラー表示ハードウェア上で画像を表示するために使用できます。
推奨パレットは、トゥルーカラーハードウェア上で動作するビューアーには関係ありません。
sPLT チャンクを使用して推奨パレットを提供する場合、
エンコーダーは、すべてをゼロのままにする
（未定義を意味する）のではなく、頻度フィールドを使用してパレットエントリーの相対的重要度を示すことが
推奨されます。頻度値は、「最近傍」カウント、すなわち
ディザリングを適用しない場合の各 RGBA パレットエントリーのおおよその
使用回数として計算するのが最も簡単です。（これらのカウントは、推奨パレットの作成に伴って
「追加コストなしで」得られることがよくあります。）
推奨パレットには透明度情報が含まれているため、
まだ合成されていない画像に対して計算する必要があります。
インデックスカラー画像の場合でも、sPLT を使用して、
PLTE
チャンクに存在するすべての色を表示できないビューアー向けの代替減色パレットを定義できます。PLTE チャンクが bKGD
チャンクを伴わずに、カラータイプ 6 の画像に現れる場合、パレットが計算された
条件は規定されていません。
トゥルーカラー
PNG データストリームに推奨パレットを含める従来の方法では、PLTE
チャンクを使用します。この方法を使用する場合、ヒストグラム（頻度）は
別個の hIST チャンクに現れる必要があります。PLTE
チャンクには透明度情報が含まれません。
したがって、カラータイプ 6（アルファ付き
トゥルーカラー）の画像では、bKGD チャンクを含め、
指定された背景色に対して合成した後の画像の表示に基づいて
パレットとヒストグラムを計算することが推奨されます。この定義は、
小数のアルファ値を持つピクセルに対して有用なパレットエントリーを
生成するために必要です。結果として得られるパレットは、
同じ背景色に対して画像を表示するビューアーにのみ有用である可能性が高くなります。PNG エディターが、カラー
タイプ 6 の画像内の bKGD チャンクを変更または削除した場合は、
パレットを削除または再計算することが推奨されます。
カラータイプ
2（トゥルーカラー）の画像では、PLTE および hIST チャンクを、
透明色の指定を無視して、RGB データのみを基準として
計算することが推奨されます。データストリームが透明度を使用する（tRNS
チャンクを持つ）場合、ビューアーは結果として得られるパレットを、
使用する予定の背景色に合わせて容易に調整できます（
13.17
ヒストグラムおよび推奨パレットの使用法を参照）。
推奨パレットを提供する場合、sPLT チャンクは、次の点で
PLTE チャンクよりも柔軟です。
- sPLT を使用すると、複数の推奨パレットを提供できます。PNG
デコーダーは、名前またはエントリー数に基づいて
適切なパレットを選択できます。
- カラータイプ 6（アルファ付き
トゥルーカラーチャンネル）の PNG データストリームでは、PLTE チャンクは、
bKGD の色に対してすでに合成されたパレットを表すため、その背景色に対する表示にのみ有用です。
sPLT チャンクは、まだ合成されていないパレットを提供し、
PNG デコーダーが選択した背景に対する表示に
使用できます。
- sPLT チャンクは補助チャンクであるため、PNG
エディターは、複製しても安全でない未知のチャンクを破棄することを強制されることなく、
推奨パレットを追加または変更できます。
- sPLT チャンクは、カラー
タイプ 0、3、
および 4（グレースケールおよびインデックスカラー）の PNG データストリームで許可されていますが、PLTE チャンクを使用して、これらの場合に減色
パレットを提供することはできません。
- sPLT チャンクには、256 個を超えるエントリーを含めることができます。
sPLT チャンクを使用する PNG エンコーダーは、
PLTE および hIST
チャンクで表される推奨パレットも書き込むことを選択できます。これは、
sPLT チャンクを認識しないデコーダーとの互換性を確保するためです。
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 コードポイントを超える単一行のテキストの作成を避けるよう促す必要があります。
サイズが 1024 バイト未満のテキスト項目は、非圧縮テキスト
チャンクを使用して出力することが推奨されます。
基本的なタイトルおよび作者のキーワードは、非圧縮テキストチャンクを使用して出力することが推奨されます。大きなテキスト
チャンクを
画像
データの後（IDAT チャンクの後）に配置すると、デコーダーが最初に
画像データをデコードするため、状況によっては画像の表示を高速化できます。画像のタイトルなどの小さなテキストチャンクは、
IDAT チャンクの前に現れることが推奨されます。
エンコーダは、他のアプリケーションが理解する必要のない情報を保持するためにプライベートチャンクを使用しても MAY です。
エンコーダは実験的またはプライベート利用のために非予約フィールド値を使用しても MAY です。
すべての補助チャンクは任意であり、エンコーダはそれらを書かなければならないわけではありません。しかし、情報が利用可能な場合は標準的な補助チャンクを書くことが推奨されます。
本節は PNG デコーダおよびビューアの振る舞いに関するいくつかの要件と推奨事項を示します。ビューアは復号された PNG
イメージをユーザに提示します。ビューアとデコーダの振る舞いは密接に関連しているため、ここではデコーダとビューアを一緒に扱います。PNG
デコーダに対する唯一の絶対的な要件は、前章で規定された形式に準拠する任意のデータストリームを正しく読み取ることができることです。ただし、通常は以下の追加の推奨事項に従うことでより良い結果が得られます。
PNG デコーダは、本国際規格で明示的に定義された、ビット深度、color type、圧縮方式、filter
method、およびインターレース方式のすべての有効な組合せをサポートしなければなりません。
PNG データストリームのエラーは大きく二つのクラスに分かれます：伝送エラーと構文エラーです（4.10 Error handling を参照）。
伝送エラーの例としては、バイトコード 13 および/または 10
がデータストリーム全体にわたって追加・削除・変換される「text」や「ascii」モードでの伝送、データストリームが切断される予期しない終了、あるいは記憶装置上の物理エラーでブロック（通常 512
バイト単位）が乱れたりランダムな値になる場合などがあります。構文エラーの例としては、行フィルタの無効な値、無効な圧縮方式、無効なチャンク長、インデックス画像で最初の IDAT チャンクの前に PLTE チャンクがないこと、あるいは複数の gAMA チャンクの存在などがあります。PNG デコーダは次のようにエラーを処理するべきです：
- PNG シグネチャバイトや各チャンクの CRC を用いて、できるだけ早期にエラーを検出すること。デコーダは PNG シグネチャの全 8 バイトが正しいことを検証すべきです。次の 8
バイトが正しいチャンク長を持つ IHDR
チャンクで始まる場合、データストリームの整合性に対する追加の信頼が得られます。チャンクデータを処理する前に CRC をチェックするべきです。ストリーミング PNG デコーダが大きな IDAT チャンクを処理しているような場合は実用上難しいことがありますが、その場合はチャンク終端に到達した時点で CRC をチェックすべきです。
- 可能ならばエラーから回復し、そうでなければ優雅に失敗すること。画像処理にほとんど影響のないエラーは無視できる一方、重要なデータに影響するエラーはアプリケーションに適した方法で扱うべきです。
- 回復可能なエラーを含め、エラーを説明する有用なメッセージを提供すること。
この方針に関連する PNG
チャンクのクラスは三種類あります。この分類における「未知のチャンク」とは、デコーダ作成者にとって真に型が不明なチャンク、あるいは作成者が扱いを既定の方法（デフォルトハンドリング）に任せたために「未知」と扱うことにしたチャンクを指します。他のチャンクは「既知のチャンク」と呼ばれます。この定義に基づく三つのクラスは次のとおりです：
- 既知のチャンク。これは本仕様で定義されたすべてのクリティカルチャンク（IHDR, PLTE, IDAT, IEND）を必ず含みます。
- 未知のクリティカルチャンク（チャンクタイプの最初のバイトのビット5が 0）
- 未知の補助（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
があることを致命的なエラーと見なすかもしれません。構文エラー以外の異常な状況は次のように扱うべきです：
- 未知の補助チャンクに遭遇することは決してエラーではありません。そのチャンクは単に無視できます。
- 未知のクリティカルチャンクに遭遇することは、データストリームから画像を抽出しようとする任意のデコーダにとって致命的な状態です。クリティカルチャンクを無視したデコーダは、エンコーダが意図した画像を抽出したかどうかを判断できなくなります。
- 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 を参照してください。
不適切に書かれたデコーダはチャンクが極めて大きく（最大 231-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]：
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. ガンマと色度で、
ガンマに関する問題の簡単な説明を参照してください。
完全なカラーマネジメントに対応するビューアーは、ここで説明するものよりも
高度な計算を実行します。
画像表示プログラムが正しい階調再現を行うには、
サンプルと表示出力の関係、および表示
システムの伝達関数を考慮する必要があります。これは、次のように
計算できます。
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 は
フレームバッファーに書き込む値、MAX_FRAMEBUF_SAMPLE は
フレームバッファーサンプルの最大値（8
ビットでは 255、5 ビットでは 31 など）です。最初の行は整数サンプルを正規化された浮動
小数点値（0.0 から 1.0 の範囲）に変換し、2 行目は目的の表示出力強度に比例する値に変換し、
3 行目は表示
システムの伝達関数を考慮し、4 行目は整数の
フレームバッファーサンプルに変換します。ゼロを
任意の正の数で累乗するとゼロになります。
2 行目と 3 行目の間に、実際の観察条件と基準観察条件の
差を考慮して display_output を調整するステップを挿入できます。ただし、この調整では
ベイリンググレア、ブラックマッピング、および色の見えモデルを考慮する必要があり、これらはいずれも
べき関数では十分に近似できません。このような
計算については、ここでは説明しません。観察条件を無視しても、通常、誤差はわずかです。
表示装置の伝達関数は通常、指数
display_exponent を持つべき関数で近似できます。この場合、2 行目と 3 行目を次のように統合できます。
display_input = sample1.0/(gamma * display_exponent) = sampledecoding_exponent
これにより、べき乗計算を 1 回だけ実行できます。カラー画像では、計算全体を
R、G、
および B の値ごとに個別に実行します。
ガンマ値は、gAMA
チャンクから直接取得できます。あるいは、
アプリケーションがガンマ値に影響を与えることで、表示画像の外観をユーザーが調整できるようにしてもかまいません。
たとえば、ユーザーがデフォルト値 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 チャンクは意味を持ちませんが、
誤って現れる可能性があります。デコーダーは
これを無視する必要があり、エディターはこれを破棄してユーザーに警告を発してもかまいません。
ピクセルごとに超越数学演算を実行する必要はありません。代わりに、
あらゆるサンプル値に対して正しい出力値を示すルックアップテーブルを計算できます。これに必要なのは、ピクセルごとに 1 回または 3 回の計算ではなく、
画像ごとに 256 回
（8 ビット精度の場合）の計算だけです。インデックスカラー画像では、画像が透明度を使用し、
不均一な
背景に対して表示される場合を除き、パレットを一度補正すれば十分です。
浮動小数点計算ができない場合、ガンマ補正テーブルは、整数演算
および事前計算された対数表を使用して計算できます。コード例は [PNG-EXTENSIONS] にあります。
入力画像のガンマ値が不明な場合（gAMA、sRGB、および iCCP がすべて存在しない場合）、スタンドアロンの画像ビューアーは、
妥当と思われるデフォルトのガンマ値を選択する必要がありますが、結果が
暗すぎるか
明るすぎる場合は、ユーザーが新しい値を選択できるようにする必要があります。デフォルトのガンマ値は、画像に関する他の情報、たとえば画像が
インターネットから取得されたものか
ローカルシステムから取得されたものかによって異なる場合があります。一貫性を保つため、HTML などの文書形式や、
SVG などのベクター
グラフィックスのビューアーは、埋め込みまたはリンクされた PNG 画像でガンマ値が不明なものを、
他の
タグ付けされていない画像と同じように扱う必要があります。
実際には、使用すべき表示指数の値を決定するのが困難なことがよくあります。組み込みの
ガンマ
補正がないシステムでは、表示指数はCRTによって完全に決まります。使用する特定の CRTについて詳細な較正測定値が利用できない限り、
2.2 の表示指数を使用する必要があります。
多くの最新のフレームバッファーには、ガンマ
補正を実行するために使用されるルックアップテーブルがあり、このようなシステムでは、
表示指数の値は、ルックアップテーブルとCRTを組み合わせた指数とする必要があります。ビューアーアプリケーション内から
ルックアップテーブルの内容を確認できない場合があり、その場合は、
表示システムの指数値をユーザーに
入力してもらう必要があります。残念ながら、ルックアップテーブルに何を
格納すべきかを指定する方法はメーカーごとに異なるため、システムのガンマ値の解釈は
システムに依存します。
実際の表示装置の応答は、単一の数値（表示指数）では説明できないほど複雑です。
電圧入力に対するモニターの光出力の実測値を利用できる場合は、
上記の計算の 3 行目と 4 行目を、これらの測定値の参照に置き換えて、目的の明るさに最も近い実際のフレームバッファー値を
求めることができます。
色に関する参照は 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 から、画像の表示に使用するモニターの表示 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 などの中間グレーが妥当な
選択となります。一般的に使用される透明な
黒色または白色のテキストや暗いドロップシャドウは、いずれもこの
背景上で判読できます。
画像を表示するための特定の背景を持つビューアー（Web ブラウザーなど）は、
bKGD チャンクを無視し、実質的に bKGD を自身の
優先する背景色または背景画像で上書きする必要があります。
bKGD チャンクによって指定された背景色は、
tRNS チャンクによって指定された色とたまたま一致する場合でも（または、
インデックスカラー画像の場合、tRNS
チャンクによって透明とマークされたパレットインデックスを参照する場合でも）、
透明であると見なしてはなりません。そうでなければ、合成の対象となる何かが「背景の背後」にあると想定しなければならなくなります。背景
色は、背景として使用されるか、無視されるかのいずれかであり、PNG 画像と
他の何らかの背景との間にある中間レイヤーでは
ありません。
実際、bKGD チャンクと tRNS
チャンクが同じ色を指定することは一般的です。その場合、透明度処理を実装していないデコーダーでも、
少なくとも半透明のピクセルが存在しない場合には、意図された
表示を生成できるためです。
アルファチャンネルを使用して、前景画像を背景画像に対して合成できます。PNG
データストリームは
前景画像と透明度マスクを定義しますが、背景画像は定義しません。PNG デコーダーには、
この最も一般的なケースのサポートは要求されません。
ほとんどのデコーダーは、単一の
背景色に対する合成をサポートできると期待されます。
合成後のサンプル値を計算する式は次のとおりです。
output = alpha * foreground + (1-alpha) * background
ここで、alpha、入力サンプル値、および出力サンプル値は、0 から 1 の範囲の分数として表されます。この
計算は、
強度サンプル（ガンマ符号化されたサンプルではない）を使用して実行する必要があります。カラー画像では、この計算を
R、G、および B のサンプルごとに
個別に実行します。
次のコードは、前景画像を背景
画像に対して合成する一般的なケースを示しています。このコードでは、
背景画像の元のピクセルデータが利用可能であり、出力先が表示用のフレームバッファーであると想定しています。
他のバリエーションも可能です。コードの下にあるコメントを参照してください。このコードでは、前景画像と背景画像のサンプル深度およびガンマ値が
すべて異なり、表示システムに必ずしも適していない場合にも対応します。実際には、
最初に確認することなく、それらが等しいと
想定してはなりません。
このコードは ISO C [ISO_9899] であり、
以下のコメントで参照するために行番号が追加されています。
01 int foreground[4];
02 int background[3];
03 int fbpix[3];
04 int fg_maxsample;
05 int bg_maxsample;
06 int fb_maxsample;
07 int ialpha;
08 float alpha, compalpha;
09 float gamfg, linfg, gambg, linbg, comppix, gcvideo;
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;
13 ialpha = foreground[3];
14 if (ialpha == 0) {
15 ;
16 } else if (ialpha == fg_maxsample) {
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 {
25 alpha = (float) ialpha / fg_maxsample;
26 compalpha = 1.0 - alpha;
27 for (i = 0; i < 3; i++) {
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);
32 comppix = linfg * alpha + linbg * compalpha;
33 gcvideo = pow(comppix, 1.0 / display_exponent);
34 fbpix[i] = (int) (gcvideo * fb_maxsample + 0.5);
35 }
36 }
バリエーション：
- 出力先がフレームバッファーではなく別の PNG データストリームである場合、21、22、33、および 34 行目を
次のように
変更する必要があります。
gamout = pow(comppix, outfile_gamma);
outpix[i] = (int) (gamout * out_maxsample + 0.5);
さらに、
単にピクセルをスキップするのではなく、alpha がゼロの場合にも背景ピクセルを処理する
必要があります。したがって、15
行目を 17～23 行目のコピーで置き換える必要がありますが、前景
ピクセル値ではなく背景ピクセル値を処理します。
- 出力ファイル、前景ファイル、および背景ファイルのサンプル深度がすべて同じであり、
3 つのガンマ
値も一致する場合、14～23 行目の非合成コードは、alpha が 1 なら入力ファイルから
出力ファイルへピクセル値をコピーし、alpha が
ゼロなら背景から出力ファイルへピクセル値をコピーするだけになります。通常、画像内の大部分のピクセルでは alpha が
ゼロまたは 1 であるため、処理を大幅に
削減できます。大部分のピクセルではガンマ
計算は必要ありません。
- サンプル深度とガンマ値がすべて一致する場合、
ガンマ
デコード
および符号化（28～31、33～34 行目）を省略し、ガンマ符号化されたサンプル
値を使用して 32 行目だけを実行したくなるかもしれません。これは
画質にそれほど悪い影響を与えませんが、ここで推奨されているように alpha 値がゼロと 1 の場合を
特殊なケースとして扱うと、短縮できる
時間はわずかです。
- 背景画像の元のピクセル値が利用できなくなり、背景画像を表示した後の処理済みのフレームバッファーピクセルだけが
残っている場合、30 行目と 31 行目では、次のようなコードを使用してフレームバッファーピクセル
値から強度を抽出する必要があります。
gcvideo = (float) fbpix[i] / fb_maxsample;
linbg = pow(gcvideo, display_exponent);
ただし、丸め
誤差が生じる可能性があるため、可能であれば元の背景ピクセルを利用できるようにしておく方が
適切です。
- 18～22 行目では、アルファ
チャンネルが存在しない場合に実行されるものとまったく同じガンマ計算が実行されることに注意してください。
アルファなしのケースをルックアップテーブルで処理する場合、同じルックアップテーブルをここでも使用できます。
28～31 行目および 33～34 行目も
（異なる）ルックアップテーブルを使用して処理できます。
- 処理全体を通して十分な精度を維持するよう注意すれば、浮動小数点演算の代わりに整数演算を
使用できます。
注記
注記 浮動小数点演算では、入力サンプル
値が
0 から 1 の間であることが保証されており、合成によって得られる結果も常に
入力値の間（両端を含む）となるため、オーバーフローやアンダーフローの検査は必要ありません。
整数演算では、オーバーフローや
アンダーフローが発生しないことを保証するために、丸め誤差の分析が必要になる場合があります。
完全なアルファチャンネルを持つ PNG 画像を表示する場合、たとえ黒だけであっても、何らかの
背景に対して画像を合成できることが重要です。アルファチャンネルを無視すると、
関連付けられたアルファ表現から変換された PNG 画像が
正しく表示されなくなります。（もちろん、アルファチャンネルが独立した
透明度マスクである場合は、
アルファを無視することも有用な選択肢です。これにより、画像の隠れた部分を復元できます。）
デコーダーが真の合成ロジックを実装していない場合でも、アルファ値がゼロと
1 だけの画像は簡単に処理できます。（これは、グレースケールおよびトゥルーカラーの PNG データストリームで
tRNS チャンクを使用する場合には暗黙的に当てはまります。インデックスカラー PNG
データストリームでは、tRNS チャンクに
0 と 255 以外の値が含まれているかどうかを簡単に確認できます。）この単純なケースでは、透明なピクセルが
背景色に置き換えられ、それ以外のピクセルは変更されません。
デコーダーの透明度処理能力がこの程度しかない場合、完全なアルファチャンネルを、
ゼロ以外のすべてのアルファ値を完全に不透明として扱うか、ディザリングすることによって処理する必要があります。
どちらの方法でも、関連付けられたアルファ形式から変換された
画像では良好な結果は得られませんが、何もしないよりは適切です。完全なアルファを二値アルファへ
ディザリングすることは、
グレースケールを白黒へディザリングすることとよく似ています。ただし、完全に透明なピクセルと完全に不透明なピクセルはすべて、
ディザー処理によって変更されないようにする必要が
あります。
インデックスカラーハードウェア上で動作し、トゥルーカラー画像、または
パレットがフレームバッファーに対して大きすぎるインデックスカラー画像を
表示しようとするビューアー向けに、エンコーダーが
sPLT チャンク内に 1 つ以上の推奨パレットを提供している場合があります。サイズや
場合によっては名前に基づいて、そのいずれかが適切であると判断された場合、
PNG デコーダーはそのパレットを使用できます。デコーダーが必要とするものとは異なるサンプル深度を持つ推奨パレットは、
サンプル深度の再スケーリングを使用して
変換できます（13.12
サンプル深度の再スケーリングを参照）。
背景が単色の場合、ビューアーは画像と推奨
パレットをその色に対して合成し、その後、結果として得られた画像を、結果として得られた
RGB パレットに量子化する必要があります。画像が透明度を使用し、背景が
単色でない場合、有用な推奨パレットは存在しない可能性が高くなります。
トゥルーカラー画像では、推奨パレットが PLTE
チャンク内にも提供されている場合があります。画像に tRNS チャンクがあり、背景が単
色の場合、ビューアーは
推奨パレットを目的の背景色で使用できるように調整する必要があります。そのためには、
tRNS の色に最も近いパレットエントリーを目的の背景色に置き換えるか、
または、ビューアーが
PLTE のエントリー数よりも多くの色を処理できる場合は、背景色のパレットエントリーを追加できます。
カラータイプ
6（アルファ付き
トゥルーカラー）の画像では、すべての PLTE チャンクが、
bKGD チャンクによって指定された色の均一な背景に対して画像を表示するように設計されている
必要があります。ビューアーが別の
背景を使用する場合、または bKGD チャンクがない場合は、おそらくパレットを無視する必要があります。ビューアーは、
意図されたものとは異なる背景に対する
表示に推奨パレットを使用できますが、結果があまり良くない場合があります。
ビューアーが透明なトゥルーカラー画像を、均一な
色より複雑な背景に対して表示する場合、推奨パレットが合成画像に最適である可能性は低くなります。この
場合、トゥルーカラー PNG 画像と背景画像に対してトゥルーカラー合成ステップを実行し、
その後、結果として得られた画像を色量子化するのが最善です。
トゥルーカラー
PNG データストリームで、PLTE チャンクと sPLT
チャンクの両方が現れる場合、PNG デコーダーは、
上述した透明度の意味の違いを考慮しながら、両方によって推奨されたパレットの中から選択
できます。
sPLT および hIST チャンク内の頻度は、
ビューアーが PNG データストリーム内のパレットで使用されている数と同じだけの色を提供できない場合に役立ちます。
ビューアーで不足するのが
数色だけの場合、通常は最も使用頻度の低い色をパレットから削除すれば十分です。色数を
大幅に減らすには、
既存のパレットの部分集合を使用しようとするより、まったく新しい代表色を選択するのが最善です。
これは新しい色量子化ステップを実行することに相当します。ただし、既存の
パレットとヒストグラムを
入力データとして使用できるため、IDAT
チャンク内の画像データを走査せずに済みます。
推奨パレットが提供されていない場合、デコーダーは、IDAT チャンク内の
画像
データを追加でもう一度処理することにより、独自のパレットを作成できます。あるいは、デフォルトのパレット
（おそらくカラーキューブ）を
使用できます。
12.5 推奨
パレットも参照してください。
