本条款给出了对编码器行为的要求和建议。PNG 编码器应当从一个 PNG 图像生成一个符合前述条款中所规定格式的 PNG 数据流。遵循此处给出的额外建议通常能得到更好的结果。
有关 C. 伽玛与色度 中的简要介绍，请参阅 gamma 相关问题。
具备完整色彩管理能力的 PNG 编码器将比此处描述的执行更复杂的计算，并可能选择使用 iCCP 块。如果已知图像采样符合 sRGB 规范
[SRGB]，
强烈建议编码器写入 sRGB 块，而无需进行额外的 gamma 处理。在这两种情况下，建议生成一个适当的 gAMA 块，以供不识别 iCCP 或 sRGB 块的 PNG 解码器使用。
PNG 编码器必须确定：
- 在 gAMA 块中写入什么值；
- 如何将提供的图像采样转换为要写入 PNG 数据流的值。
写入 gAMA 块的值应当是能使 PNG 解码器按期望方式工作的那个值。参见 13.13 解码器伽玛处理。
要应用的变换取决于图像样本的性质及其精度。如果样本以浮点或高精度整数形式表示光强（例如来自计算机图形渲染器），编码器可以在量化为整数并写入 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
如果无法确定原始图像捕获或计算的条件是否需要这种对比度变化，则可假定显示强度与原始场景强度成比例，即端到端指数为 1，因此：
gamma = encoding_exponent
如果图像仅写入数据流，编码器可以自由选择 encoding_exponent。通常将 gAMA 块中的 gamma 值设为 1/2.2
是一个合理选择，因为这会将解码器在典型视频监视器上显示时的工作量最小化。
一些图像渲染器可能同时将图像写入 PNG 数据流并在屏幕上显示。屏幕上显示的像素应根据正在使用的显示系统与观看条件进行 gamma 校正，以便用户看到与原始场景相符的正确表现。
如果渲染器想将已显示的采样值写入 PNG 数据流，从而避免对数据流进行单独的 伽玛编码，渲染器应通过幂函数近似显示系统的 传递函数，并将该幂函数的倒数写入 gAMA
块。这将允许 PNG 解码器重现渲染器在渲染期间在屏幕上显示的内容。
然而，渲染器也可以为显示设备计算合适的显示像素，并为数据存储与传输执行单独的 伽玛编码，并在 gAMA 块中写入更适合图像未来使用的值。
计算机图形渲染器通常不执行 伽玛编码，而是直接使样本值与场景光强成正比。如果 PNG 编码器接收到的样本值已经被量化为整数，则对它们再做 伽玛编码 没有意义；那只会造成额外的信息损失。编码器应将这些样本值直接写入 PNG 数据流。这并不意味着 gAMA 块应当包含 gamma value 为 1.0，因为从场景强度到显示输出强度的期望端到端 传递函数 不一定是线性的。不过，期望的 gamma value 可能接近
1.0。其值可能取决于场景是日光场景还是室内场景等因素。
当样本值直接来自硬件时，正确的 gAMA 值原则上可以从硬件的 传递函数
以及场景的照明条件推断出来。对于视频采集卡（“帧抓取器”），样本很可能处于 sRGB 色彩空间，因为 sRGB
规范设计时考虑了与现代视频标准的兼容性。图像扫描仪则更难预测：它们的输出可能与输入光强成正比（CCD 传感器本身是线性的），也可能在硬件层面上应用了用于补偿印刷点增益的幂函数（大约 0.57
的指数），或者已对样本进行显示校正。确定特定扫描仪的特性可能需要参考其手册或扫描一个校准目标。应记住 gamma 关系的是样本与期望显示输出之间的关系，而不是与扫描仪输入之间的关系。
数据流格式转换器通常不应试图将提供的图像转换为不同的 gamma。数据应在无转换情况下存储在 PNG 数据流中，并应尽可能从源数据流中推断出应写入的 gamma value。在数据流转换时改变 gamma
会导致所表示的强度级集合被重新量化，从而引入更多舍入误差而收益甚微。通常最好直接将输入样本值从输入复制到输出文件，而不进行转换。
如果源数据流描述了图像的 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 不适用于
alpha 采样；alpha 始终以线性方式表示。
另见 13.13 解码器伽玛处理。
关于色彩问题的参考，请参阅 C. 伽玛与色度。
具备完整色彩管理能力的 PNG 编码器将执行比此处描述的更复杂的计算，并可能选择使用 iCCP 块。如果已知图像采样符合 sRGB 规范
[SRGB]，强烈建议
PNG 编码器使用 sRGB 块。
如果编码器能确定源显示器三基色的色度，或能根据图像的来源或运行它的硬件做出有力的猜测，强烈建议编码器输出 cHRM 块。如果写入了 cHRM 块，也应写入 gAMA 块；若没有 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]，其值见
表 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
数据流中不经转换地存储，并应记录源基色的色度（如果已知）。在数据流转换时进行色彩空间变换通常不可取，原因是色域不匹配和舍入误差。与 gamma
转换类似，最好无损地存储数据，并在图像最终显示时最多执行一次转换。
另见 13.14 解码器色彩处理。
Alpha 通道可以被看作是暂时隐藏图像透明部分的掩码，或者用来构造非矩形图像。在第一种情况下，完全透明像素的颜色值应当保留以备将来使用。在第二种情况下，透明像素不携带有用数据，仅用于填充 PNG
所需的矩形图像区域。在这种情况下，为获得最佳压缩，应将所有完全透明像素赋予相同的颜色值。
图像作者应记住，解码器可能不会完全支持透明控制（见 13.16
Alpha 通道处理）。因此，在可行的情况下，分配给透明像素的颜色应当尽量是合理的背景颜色。
对于不需要完整 alpha 通道或无法承受压缩效率代价的应用，也可以使用 tRNS 透明块。
如果图像有已知的背景色，应将该颜色写入 bKGD 块。即便忽略透明性的解码器也可以使用 bKGD 颜色来填充未用的屏幕区域。
如果原始图像具有预乘（也称为“关联”）alpha 数据，可以通过将每个样本值除以相应的 alpha 值，然后乘以图像位深的最大值，并四舍五入到最近的整数，将其转换为 PNG
的非预乘格式。在有效的预乘数据中，样本值从不超过相应的 alpha 值，因此除法结果应始终在 0 到 1 的范围内。如果 alpha 值为零，则输出黑色（零值）。
当编码输入样本的样本深度不能被 PNG 直接表示时，编码器应将样本缩放到 PNG 允许的样本深度。最精确的缩放方法是线性方程：
output = floor((input * MAXOUTSAMPLE / MAXINSAMPLE) + 0.5)
其中输入样本的范围为 0 到 MAXINSAMPLE，输出范围为 0 到 MAXOUTSAMPLE
（即 2sampledepth-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
位的样本深度时它有助于改善压缩。由于在高样本深度时零填充引入的相对误差较小，一些编码器可能选择使用它。但对于 alpha 通道数据不得使用零填充，因为许多解码器会将全零与全一的 alpha
值视为特殊情况。因此必须在缩放数据中精确表示这两个值。
当编码器写入 sBIT 块时，要求按这样的方式进行缩放：已存储样本的高位应与原始数据匹配。也就是说，如果 sBIT 块指定了 S 位的样本深度，则存储数据的高 S 位应与原始 S
位数据值一致。这样解码器可以通过右移恢复原始数据。低位没有约束。以上所有缩放方法都满足此限制。
在扩展源 图像数据
时，建议一致地填充低位；即相同的源值应在任何像素位置生成相同的样本值。这可以通过减少不同样本值的数量来改善压缩。这并非强制要求，某些编码器可能不遵循此建议，例如它们可能对低位执行抖动以提高显示图像质量，但代价是增大文件体积。
在某些应用中，原始源数据的范围可能不是 2 的幂次。线性缩放方程对这种情况仍然适用，而移位方法则不适用。建议在此类图像上不要写入 sBIT
块，因为 sBIT 暗示原始数据范围正好是 0..2S-1。
本规范定义了两种隔行方法，其中一种是不隔行。隔行为解码器提供了一个便于渐进式显示图像的基础，如 13.10 隔行与渐进显示 所述。
对于 color
type 3（索引色）图像，滤波类型 0（None）通常是最有效的。具有 256 色或更少颜色的彩色图像几乎总是应以 indexed-color 格式存储；以 truecolor 格式存储可能会大得多。
对于位深小于 8 的图像，也推荐使用滤波类型 0。对于低位深灰度图像，在极少数情况下，先将图像扩展到 8 位再应用滤波可能得到更好的压缩。
对于 truecolor 和 greyscale
图像，五种滤波器中的任何一种都可能是最有效的。如果编码器使用固定滤波，Paeth 滤波类型最有可能表现最好。
为了在 truecolor 和 greyscale
图像上获得最佳压缩，并且当压缩效率比压缩速度更重要时，建议使用自适应滤波：为每条扫描线选择滤波类型。每幅图像最佳的滤波集合各不相同。编码器可以尝试所有滤波组合以找到对给定图像压缩效果最佳的方案。然而，当无法进行穷尽式搜索时，以下启发式方法通常效果足够好：对每条扫描线分别用五种滤波器生成输出，并选择能使输出字节绝对值之和最小的滤波器（在此测试中将输出字节视为有符号差值）。这种方法通常优于任何单一固定滤波类型的选择。
根据这些建议进行的滤波在与本规范定义的任一隔行方法配合时均有效。
编码器可以按任意方式将压缩后的数据流划分为 IDAT 块。（允许多个 IDAT 块，以便编码器在固定内存量下工作；通常块大小对应编码器的缓冲区大小。）一个 PNG 数据流中每个 IDAT 块仅包含一个数据字节的情况是有效的，尽管极其浪费空间。（零长度 的 IDAT 块也是有效的，但更加浪费。）
每个文本块必须提供非空关键字。如果没有更合适的描述，可以使用通用关键字 "Comment"。如果使用用户提供的关键字，编码器应检查其是否符合关键字的限制。
iTXt 块使用 Unicode 的 UTF-8 编码，因此可以存储任何语言的文本。tEXt 与 zTXt 块使用 Latin-1（ISO
8859-1）字符编码，这限制了这些块中可用字符的范围。编码器应优先使用 iTXt，而不是 tEXt 与 zTXt，以允许广泛字符而不丢失数据。编码器必须在存储文本时将使用本地传统字符编码的字符转换为相应的目标编码（参见 legacy character
encodings）。
创建 iTXt 块时，编码器应遵循 Encoding Standard 中的 UTF-8 encode 规范。
编码器应劝阻创建长度超过 79 个 Unicode code points 的单行文本，以便易于阅读。建议将小于 1024
字节的文本项以未压缩文本块输出。建议将基本的标题和作者关键字使用未压缩的文本块输出。将大文本块放在 图像数据 之后（即 IDAT 块之后）在某些情况下可以加快图像显示，因为解码器会先解码 图像数据。建议将小文本块（例如图像标题）放在 IDAT 块之前。
编码器 MAY 使用私有块来携带不必被其他应用理解的信息。
编码器 MAY 使用非保留的字段值进行实验或私用。
所有辅助块均为可选，编码器无需写入它们。不过，当相关信息可用时，鼓励编码器写入标准的辅助块。
本条款给出了一些关于 PNG 解码器行为与查看器行为的要求与建议。查看器将解码后的 PNG 图像呈现给用户。由于查看器与解码器行为密切相关，这里将二者一并讨论。对 PNG
解码器的唯一绝对要求是它必须能成功读取任何符合前述章节中指定格式的数据流。然而，遵循下列附加建议通常会得到更好的效果。
PNG 解码器应支持本国际标准中明确定义的所有有效的位深、颜色类型、压缩方法、滤波方法和隔行方法的组合。
PNG 数据流中的错误大致可分为两类：传输错误与语法错误（见 4.10
错误处理）。
传输错误的例子包括以“文本”或“ascii”模式传输，在此模式下字节码 13 和/或 10 可能在整个数据流中被添加、删除或转换；意外终止，即数据流被截断；或存储设备的物理错误，其中一个或多个块（通常为每块
512 字节）会出现损坏或随机值。语法错误的例子包括行滤波器的无效值、无效的压缩方法、无效的块长度、在索引图像中第一个 IDAT
块之前缺少 PLTE 块，或存在多个 gAMA 块。PNG
解码器应如下处理错误：
- 尽早检测到错误，利用 PNG 签名字节和每个块的 CRC。解码器应验证 PNG 签名的全部八个字节是否正确。如果接下来的八个字节以正确的块长度开始一个 IHDR 块，则可进一步增强对数据流完整性的信心。在处理块数据之前应检查校验和（CRC）。有时这并不现实，例如当流式 PNG 解码器正在处理一个大型 IDAT 块时。在这种情况下，应在到达该块结尾时检查 CRC。
- 在可能的情况下从错误中恢复；否则优雅地失败。对图像处理影响很小或没有影响的错误可以被忽略，而那些影响关键数据的错误应以适合应用的方式处理。
- 提供有助于理解的错误描述信息，包括可恢复错误的说明。
与此理念相关的三类 PNG
块如下。这里定义的“未知块”要么是解码器作者确实不知道其类型的块，要么是作者选择将其视为未知的块（因为对该块类型的默认处理对程序目的已足够）。其他块称为“已知块”。在此定义下，三类为：
- 已知块，这必然包括本规范中定义的所有关键块（IHDR、PLTE、IDAT、IEND）
- 未知的关键块（块类型第一个字节的位 5 为 0）
- 未知的辅助块（块类型第一个字节的位 5 为 1）
有关块命名约定的描述，请参阅 5.4
块命名约定。
PNG 块类型根据它们对提取可查看图像（例如 IHDR、PLTE
和 IDAT）或对理解数据流结构（例如 IEND）的重要性，被标记为“关键”或“辅助”。这是一类特定的关键性，并不一定适用于每一种解码器。例如，仅用于提取文本注释（如版权信息）的程序并不需要可查看图像，但应能正确
解码 UTF-8。另一个解码器可能认为 tRNS 和 gAMA 块对其正确执行是必需的。
语法错误总是牵涉到已知块，因为在未知块中不能检测出语法错误。PNG 解码器必须根据其需求和情形判断语法错误是否为致命（不可恢复）的。例如，大多数解码器可以忽略一个无效的 IEND 块；文本提取程序可以忽略缺少 IDAT；图像查看器无法从索引图像中空的 PLTE 块中恢复，但可以忽略真彩色图像中无效的 PLTE
块；提取 alpha 通道的程序可以忽略无效的 gAMA 块，但可能认为存在两个 tRNS 块是致命错误。除语法错误外的异常情况应如下处理：
- 遇到未知的辅助块从来都不是错误。该块可以简单地被忽略。
- 遇到未知的关键块对于任何试图从数据流提取图像的解码器而言都是致命情况。若解码器忽略了关键块，则无法知道它提取的图像是否为编码器意图的图像。
- PNG 签名不匹配、CRC
不匹配或意外的流结尾表示数据流已损坏，可视为致命错误。解码器可以尝试从数据流中挽救一些内容，但损坏的程度无法预知。
当发生致命情形时，解码器应立即失败、在适当时向用户报告错误，并可选择继续显示用户已见到的任何 图像数据（即“优雅失败”）。整个应用程序无需终止。
当发生非致命错误时，解码器应在适当时向用户发出警告、从错误中恢复并继续正常处理。
在解码索引色 PNG 时，如果遇到越界的索引，解码器历来在处理此错误上有不同做法。将像素显示为不透明的黑色
是一种常见的错误恢复策略，并且本规范现已要求如此。旧的实现可能有所不同，因此编码器不应依赖解码器会有相同的行为。
不计算 CRC 的解码器应将明显的语法错误解释为数据损坏的迹象（另见 13.2
错误检查）。
压缩块（IDAT、zTXt、iTXt、iCCP）中的错误可能导致缓冲区溢出。deflate
解压器的实现者应防范此类可能性。
APNG 的设计允许在未读取完整个 数据流
之前逐帧增量显示。这意味着有些错误可能直到动画部分播放期间才被检测到。强烈建议在遇到任何错误时，解码器应丢弃所有后续帧、停止动画并恢复显示静态图像。若在动画开始前检测到错误，应显示静态图像。如适当，可向用户显示错误信息。
解码器应将乱序的 APNG 块视为错误。了解 APNG 的 PNG 编辑器 应使用序列号将其恢复到正确顺序。
PNG 的错误处理理念见 13.1 错误处理。
除非未知块是关键块，否则未知块类型不应被视为错误。
可通过检查四个字节是否都在 41-5A 和 61-7A（十六进制）范围内来检验块类型的合理性；注意仅需对未识别的块类型执行此检查。如果已知整个数据流大小（来自文件系统信息、HTTP
协议等），也可以检查块长度是否合理。如果不检查 CRC，丢失/添加字节或错误的块长度可能导致解码器步调错乱并将后续数据误解释为块头。
对于已知长度的块，例如 IHDR，解码器应将意外的块长度视为错误。本规范的将来扩展不会向现有块添加新字段；相反，会添加新的块类型来承载新信息。
应检查并将已知块字段中出现的意外值（例如 IHDR
块中的意外压缩方法）视为错误。然而，建议仅在关键块中将意外字段值视为致命错误。辅助块中的意外字段值可以通过忽略整个块并将其视为未知块来处理。（该建议假定块的 CRC 已通过验证。在不检查 CRC 的解码器中，将任何意外值视为数据流损坏的迹象更为安全。）
标准 PNG 图像应使用压缩方法 0 进行压缩。IHDR
块中的压缩方法字段保留以供将来标准化或专有变体使用。解码器应检查该字节并在其含有未识别的代码时报告错误。详情见 10. 压缩。
PNG 数据流由一系列明确定义类型的块组成。规范定义内容的块实际上可以包含任何东西，包括恶意代码。同样，IEND
块之后可能还存在数据，这些数据也可以包含任何内容，包括恶意代码。已知不存在因仅仅解码 PNG 图像而在接收者计算机上执行此类恶意代码的风险。然而，恶意应用可能将此类代码隐藏在看似无害的图像文件中，然后执行它。
与未来块类型相关的潜在安全风险目前无法详尽规定。定义将来公共块时会考虑安全问题。未知或未实现的块类型没有额外的安全风险，因为此类块将被忽略，或者至多被复制到另一个 PNG 数据流中。
iTXt、tEXt 和 zTXt 块包含要作为纯文本显示的关键字与数据。iCCP 与 sPLT 块也包含意在显示为纯文本的关键字。如果解码器在显示这些文本时不过滤控制字符，尤其是
ESC（转义）字符，某些系统或终端可能会出现不期望或不安全的行为。建议解码器过滤控制字符以避免此类风险；参见 13.7 文本块处理。
对于 eXIf 块，Exif 规范 [CIPA-DC-008]
并未明确要求标签的“值偏移”指针必须实际指向文件内的有效地址。该要求只是隐含的（参见描述 Exif IFD 结构的第 4.6.2 段）。无论如何，解码器应准备好遇到无效指针并适当处理它们。
每个块都以长度字段开始，这使得编写对试图通过伪造块溢出缓冲区的攻击免疫的解码器更容易。每个块末尾的 CRC
为防止意外损坏提供了稳健的防御。PNG 签名字节可早期检测常见的文件传输错误。
未检查 CRC 的解码器可能遭受数据损坏。此类损坏最可能的后果是图像内像素显示错误。更糟的是，如果不检查 CRC 的 IHDR 块被破坏，其宽度或高度字段被篡改，可能导致更严重的问题。参见 13.2 错误检查。
不良实现的解码器可能容易发生缓冲区溢出，因为块可以非常大，最大可达 231-1 字节。但正确编写的解码器能够处理大型块而不会遇到问题。
一些图像编辑工具历史上通过仅将被编辑区域的 alpha 通道设为零来执行“涂黑”处理，而没有同时删除实际图像数据。仅依赖图像视觉外观的用户因此面临隐私风险，因为实际图像数据可能被轻易恢复。
同样，一些图像编辑工具历史上通过重写 IHDR 中的宽度和高度来执行裁剪，而不重新编码图像数据，导致图像数据超出新宽度和高度并可能被恢复。
包含 eXIf 块的图像可能包含自动添加的数据，例如照片的 GPS 坐标，如果用户不知道 PNG 图像包含这些数据，则可能构成隐私风险。（其他包含 Exif
的图像格式，如 JPEG/JFIF，也存在相同的隐私风险。）
解码器应通过四字节的逐字面比较识别块类型；对块类型执行大小写转换是不正确的。解码器在遇到未知且辅助位为 1 的块时可以安全地忽略该块并继续显示图像。若在遇到未知且辅助位为
0（表示关键块）的块时，试图提取图像的解码器应向用户指示该图像包含不能安全解释的信息。
解码器应通过数值测试指定位来测试未知块类型的属性。测试字符是大写还是小写既效率低下且错误（若使用依赖于区域设置的大小写定义时）。
解码器不应在保留位被设为 1 时标记为错误，因为 PNG 规范的将来某个版本可能会为该位定义含义。将该位设为 1 的块与其他未知块类型以相同方式对待即可。
解码器无需测试块类型的私有位，因为该位没有功能意义，用于避免 W3C 定义的块与私人定义的块之间发生冲突。
所有辅助块都是可选的；解码器可以忽略它们。然而，解码器在适当且可行时应被鼓励解释这些块。
可以表示非方形像素（见 11.3.4.3 pHYs 物理像素尺寸），但查看器并不被要求对其进行校正；查看器可以将任何 PNG 数据流当作其像素为方形进行呈现。
当显示器的像素纵横比与 PNG 数据流中定义的物理像素尺寸的纵横比不同时，强烈建议查看器对图像进行重缩放以便正确显示。
当 pHYs 块的单位说明符为 0（单位未知）时，解码器的行为可依赖于两个像素每单位值的比率，但不应依赖它们的大小。例如，包含
(ppuX, ppuY, unit) = (2, 1, 0) 的 pHYs 块等价于包含
(1000, 500, 0) 的块；两者同样有效地表明图像像素的高度是宽度的两倍。
查看器处理图像与显示像素纵横比不一致的一种合理方法是仅沿水平方向或垂直方向扩展图像，而不是同时扩展两个方向。缩放因子可以使用以下浮点计算得到：
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，分别为十六进制 09、0C 与 0D），但其他字符，尤其是 ESC（十六进制
1B），可能构成安全隐患（因为显示硬件或软件可能会执行意外动作）。解码器不应尝试直接显示在 tEXt 或 zTXt 块中遇到的非 Latin-1 字符（换行与可能的 TAB 除外）。相反，应忽略这些字符或以可见记号显示，例如
"\nn"。参见 13.3
安全注意事项。
在处理 iTXt 块时，解码器应遵循 Encoding Standard 中的 UTF-8 decode。
尽管建议编码器将换行表示为行结束符（十六进制 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 块边界没有语义意义，可以出现在压缩数据流中的任意位置。图像数据的结构（例如扫描线边界）与 deflate
块边界或 IDAT 块边界之间没有必然关联。完整的图像数据由单一的 zlib 数据流表示，并存储在若干个 IDAT 块中；假定超过此点的关系是错误的。某些编码器实现可能会产生这些结构相关的数据流，但解码器不得依赖于此。
为了还原滤波的效果，解码器可能需要使用同一行上前一个像素的解码值、上一行中当前像素上方的像素，以及上方像素的左侧像素。这意味着解码器至少需要始终保存一行扫描线长度的 图像数据。尽管某些滤波类型不引用上一扫描线，解码器仍需在解码时始终存储每条扫描线，因为下一条扫描线可能使用引用它的滤波类型。详见
7.3 滤波。
解码器必须能够读取隔行图像。如果参考图像少于五列或少于五行，则某些通道将为空。编码器和解码器应正确处理此情况。特别地，滤波类型字节仅与非空扫描线相关；在空的缩小图像中不存在滤波类型字节。
在慢速传输链接上接收图像时，查看器可以通过渐进显示隔行图像来改善感知性能。这意味着当接收到每个缩小图像时，基于至今接收到的数据显示对完整图像的近似。一种简单而令人满意的效果是将每个接收到的像素扩展为一个矩形，覆盖尚未传输的位于该像素下方和右侧的位置。该过程可以由下述
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)
获取下一个传输的像素并绘制一个指定高度与宽度的矩形，该矩形的左上角位于指定的行与列，用像素指示的颜色填充。注意行与列以左上角的 (0,0) 为起点计数。
如果查看器将接收到的图像与背景图像合并，可能更方便只绘制接收到的像素位置（即 visit()
函数仅设置指定行列的像素，而不是整个矩形）。这会产生一种“渐显”效果，随着新图像逐步替换旧图像而显现。该方法的一个优点是可以在每个像素被替换时执行正确的 alpha
或透明度处理。如前所述，按上述方式绘制矩形会覆盖背景图像的像素；如果以后接收到的那些位置的像素是完全或部分透明的，则这些背景像素可能需要被保留。这仅在背景图像未在屏外存储时成为问题。
为了实现 PNG 的通用可互换性目标，解码器应接受所有类型的 PNG 图像：索引色、
真彩色，以及
灰度。运行在索引色显示硬件上的查看器需要能够将
真彩色
图像降级为索引色以便显示。该过程称为“色彩量化”。
一种简单且快速的色彩量化方法是将图像减少到一个固定的调色板。通常使用均匀色彩间隔的调色板（“色彩立方体”）以最小化每像素的计算。对于照片类图像，建议使用抖动以避免本应为平滑渐变区域出现难看的阶梯状轮廓；不过抖动会引入颗粒感，可能令人不悦。
通过使用为特定图像专门挑选的调色板，可以显著提高渲染质量，因为色彩立方体通常包含许多在特定图像中未被使用的条目。这种方法需要更多工作：首先是选择调色板，其次是将单个像素映射到最近的可用颜色。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 解码器伽玛处理 中所示。）
如果解码器需要将样本放大（例如，若 帧缓冲区 的样本深度大于 PNG 图像），则应使用线性缩放或在 12.4 样本深度缩放 中所述的左位复制方法。
当存在 sBIT 块时，可以通过右移到 sBIT
指定的样本深度来恢复参考的 图像数据。注意线性缩放不必然重现原始数据，因为编码器并非必须使用线性缩放将数据放大。然而，编码器必须使用一种保留高位的方法，所以右移总是有效。这是移位在某些情况下被认为比线性缩放更精确的唯一情形。解码器不必关注
sBIT 块；已存储的图像是一个有效的由 IHDR
指示的样本深度的 PNG 数据流；不过，在缩放到适合显示之前利用 sBIT 恢复原始样本通常能比忽略 sBIT 得到更准确的显示。
当将像素值与 tRNS
块值比较以检测透明像素时，应精确进行比较。因此，透明像素检测应在降低样本精度之前完成。
有关 gamma
问题的简要介绍，请参见 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），第二行转换为与期望显示输出强度成比例的值，第三行考虑显示系统的 传递函数，第四行将其转换为整数帧缓冲样本。零的任何正次幂仍为零。
可以在第二行和第三行之间插入一步，用以调整
display_output，以考虑实际观看条件与参考观看条件之间的差异。然而，这种调整需要考虑眩光、黑电平映射和色彩外观模型，这些均不能很好地用幂函数近似描述。此类计算在此不作说明。如果忽略观看条件，误差通常很小。
显示的 传递函数 通常可用指数 display_exponent
的幂函数近似，在这种情况下第二行和第三行可以合并为：
display_input = sample1.0/(gamma * display_exponent) = sampledecoding_exponent
从而只需执行一次幂运算。对于彩色图像，上述计算需要分别对 R、G 和 B 值执行。
gamma
value 可以直接从 gAMA 块取得。或者，应用程序可允许用户通过影响 gamma value 来调整显示图像的外观。例如，用户可以手动设置参数
user_exponent（默认为 1.0），应用可以设置：
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）的查看器在处理嵌入或链接的未知 gamma value 的 PNG 图像时，应与处理其他未标记图像的方式保持一致。
在实践中，确定应使用何种 display_exponent 常常很困难。在没有内建 gamma 校正的系统中，显示指数完全由 CRT 决定。除非有针对特定 CRT 的详细校准测量，否则应使用 2.2 的显示指数。
许多现代 帧缓冲 具有用于执行 gamma 校正的查找表，在这些系统上显示指数值应为查找表与 CRT
的组合指数。查看器应用内部可能无法得知查找表的内容，因而可能需要向用户询问显示系统的指数值。不幸的是，不同厂商使用不同方式来指定查找表内容，因此系统 gamma value 的解释与系统相关。
真实显示器的响应实际上比单个数值（显示指数）所能描述的要复杂得多。如果有监视器的实际测量数据（输出亮度随电压的变化），上述计算中的第三行和第四行可以被这些测量值的查表替换，以找到最接近所需亮度的实际 帧缓冲 值。
有关色彩问题的参考，请参见 C. 伽玛与色度。
在许多情况下，PNG 数据流中的 图像数据 会被视为设备相关的 RGB 值并直接显示（仅做适当的 gamma 校正）。这提供了最快的 PNG
显示方式。但除非查看器使用与原始图像作者完全相同的显示硬件，否则颜色不会与作者看到的完全一致，尤其是较暗或接近中性颜色时。cHRM
块提供了比单纯 gamma 校正更接近的颜色匹配信息。
cHRM 数据可用于将 图像数据 从 RGB 转换为 XYZ，继而进入感知线性的色彩空间（例如 CIE
LAB）。颜色可以在该空间中被划分以生成最优调色板，因为在 CIE LAB 中两种颜色的几何距离与它们在视觉上的差异高度相关（不同于例如 RGB 或 XYZ 空间）。将得到的颜色调色板再转换回 RGB
空间后，可用于显示或写入 PLTE 块。
作为图像处理应用一部分的解码器也可能将 图像数据 转换到 CIE LAB 空间以便分析。
在对色彩一致性要求极高的应用（如产品设计、科学可视化、医学、建筑或广告）中，PNG 解码器可以将 图像数据 从源 RGB 转换为用于查看图像的显示器的显示 RGB 空间。这涉及计算从源
RGB 到 XYZ 的矩阵，以及从 XYZ 到显示 RGB 的矩阵，然后合并以产生总体变换。PNG 解码器负责实现色域映射。
在具有色彩管理系统（CMS）的平台上运行的解码器可以将 图像数据、gAMA 和 cHRM 值传递给 CMS 以供显示或进一步处理。
提供颜色打印功能的 PNG 解码器可以使用 PostScript Level 2 中的功能，在校准的 RGB 空间或设备无关的色彩空间（如 XYZ）中指定 图像数据。这将比简单的 RGB 到 CMYK
转换提供更好的色彩保真度。PostScript 语言参考手册 [PostScript] 给出示例。此类解码器负责在源 RGB（在 cHRM 块中指定）与目标打印机之间实现色域映射。随后由 PostScript 解释器负责产生所需颜色。
PNG 解码器可以使用 cHRM 数据来计算颜色图像的准确灰度表示。将 RGB 转换为灰度只是计算 XYZ 的 Y（亮度）分量，这是
R、G、B 值的加权和。权重取决于显示器类型，即 cHRM 块中的值。对于没有 cHRM 块的 PNG 数据流，解码器可能希望进行此转换。在这种情况下，使用 CCIR 709 基色 [ITU-R-BT.709]
作为合理的默认值是可行的。原始的 NTSC 基色 不 应被使用，除非 PNG 图像确实是为那类显示器进行过色彩平衡的。
bKGD 块给出的背景色通常用于填充图像周围未被占用的屏幕空间，以及图像内的任何透明像素。（因此，即便图像不使用透明度，bKGD 也是有效且有用的。）如果不存在 bKGD
块，查看器需要选择一个合适的背景色。若无其他信息可用，使用例如 8 位 sRGB 色彩空间中的中灰（如 153）是一个合理的选择。透明的黑色或白色文字以及常见的深色投影在该背景上都应具有良好可读性。
具有特定背景以呈现图像的查看器（例如网页浏览器）应忽略 bKGD 块，从而以其首选的背景颜色或背景图像覆盖 bKGD。
bKGD 块给出的背景色不应被视为透明，即使它恰好与 tRNS
块给出的颜色相匹配（或者在索引色图像的情况下，引用了被 tRNS
标记为透明的调色板索引）。否则就必须设想“在背景之后”还有某个东西用于与之进行 合成。背景颜色要么被用作背景，要么被忽略；它不是 PNG 图像与其他背景之间的中间层。
事实上，bKGD 与 tRNS
块常常指定相同的颜色，因为这样在没有实现透明处理的解码器上，当不存在部分透明像素时，显示效果会符合预期。
Alpha 通道可用于将前景图像与背景图像进行 合成。PNG 数据流定义前景图像和透明度掩码，但不定义背景图像。PNG
解码器不要求支持这种最一般的情况。期望大多数解码器至少能支持相对于单一背景色的合成。
用于计算合成样本值的方程为：
output = alpha * foreground + (1-alpha) * background
其中 alpha 以及输入与输出样本值均以 0 到 1 的分数表示。该计算应在强度样本上执行（而非 gamma 编码的样本）。对于彩色图像，该计算应分别对 R、G、B 样本执行。
下面的代码演示了将前景图像相对于背景图像进行合成的一般情况。它假设背景图像的原始像素数据可用，且输出目标为用于显示的 帧缓冲区。还存在其他变体；见代码下方的注释。该代码允许前景图像与背景图像的样本深度和 gamma 值 各不相同，且未必适合显示系统。实践中在未先检查之前不应做出相等性的假设。
该代码为 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 行的拷贝替换。
- 如果输出文件、前景文件与背景文件的样本深度都相同，且三者的 gamma 值 也匹配，则无合成代码（第 14-23 行）在 alpha 为 1
时可简化为从输入文件复制像素值到输出文件，在 alpha 为 0 时复制背景到输出。由于在图像中绝大多数像素的 alpha 通常为零或一，这将节省大量计算。对大多数像素不需要进行 gamma
运算。
- 当样本深度与 gamma 值 都匹配时，看似可以跳过 gamma 解码/编码（第 28-31 行、33-34 行），而仅用第 32 行对 gamma
编码的样本值执行合成。尽管这对图像质量影响不大，但如果将零和一的 alpha 视为特殊情况（如此处建议），节省的时间并不显著。
- 如果背景图像的原始像素值不可得，只有通过显示背景图像留下的处理后 帧缓冲 像素可用，则第 30 和 31
行需要通过例如如下代码从帧缓冲像素值中提取强度：
gcvideo = (float) fbpix[i] / fb_maxsample;
linbg = pow(gcvideo, display_exponent);
不过这可能产生一些四舍五入误差，因此如果可能，最好使用原始背景像素。
- 注意第 18-22 行执行的计算与在没有 alpha 通道时做的 gamma 运算是完全相同的。如果无 alpha 情况使用查找表处理，这里也可复用同一查找表。第 28-31 行与 33-34
行也可以用（不同的）查找表来完成。
- 可以使用整数算术替代浮点，只要在整个过程中注意保持足够的精度以避免溢出或下溢。
注
注：在浮点运算中不需要进行溢出或下溢检查，因为输入样本值保证在 0 和 1
之间，合成结果也总是在输入值之间（含端点）。使用整数算术时，可能需要进行一些舍入误差分析以保证没有溢出或下溢。
在显示具有完整 alpha 通道的 PNG 图像时，将图像与某个背景（即使只是黑色）合成 是很重要的。忽略 alpha 通道会使那些从关联 alpha 表现转换而来的
PNG 图像看起来错误。（当然，如果 alpha 通道是单独的透明掩码，则忽略 alpha 是一个有用的选项：它允许恢复被隐藏的图像部分。）
即便解码器未实现真实合成逻辑，也可以简单地处理只包含零和一 alpha 值的图像。（对于使用 tRNS 块的 灰度
和 真彩色
PNG 数据流，这在隐含上为真；对于 索引色 PNG 数据流，检查 tRNS 块是否仅包含 0
与 255 之外的值是容易的。）在这种简单情形下，透明像素被替换为背景色，其他像素保持不变。
如果解码器仅具备此程度的透明处理能力，它应通过将所有非零 alpha 值视为完全不透明，或通过抖动处理来应对完整 alpha 通道。对于从关联 alpha
格式转换而来的图像，这两种方法都不会产生很好结果，但总比什么都不做要好。将完整 alpha 抖动为二值 alpha 很类似于将灰度抖动为黑白，除了所有完全透明与完全不透明的像素都应在抖动过程中保持不变。
对于运行在索引色硬件上的查看器，若试图显示一幅 truecolor 图像，或一幅其调色板对 frame buffer
来说过大的索引色图像，编码器可能在 sPLT 块中提供了一个或多个建议调色板。如果根据大小或名称等判断某个建议调色板适用，PNG
解码器可以采用该调色板。样本深度与解码器需求不符的建议调色板可以通过样本深度重缩放进行转换（见 13.12 样本深度重缩放）。
当背景为纯色时，查看器应将图像与建议调色板相对于该颜色进行 合成，然后对合成后的图像进行 RGB 调色板量化。当图像使用透明度且背景并非纯色时，通常没有哪个建议调色板是有用的。
对于 truecolor 图像，建议调色板也可能以 PLTE
块的形式提供。如果图像具有 tRNS 块且背景为纯色，查看器需要使建议调色板适应其所需的背景色。为此，应将最接近 tRNS 颜色的调色板条目替换为所需的背景色；或者如果查看器能处理比 PLTE 条目更多的颜色，则可以添加一个用于背景色的调色板条目。
对于 color
type 6（truecolor with
alpha）的图像，任何 PLTE 块都应该是针对以 bKGD 块指定的颜色作为统一背景时的显示而设计的。若查看器打算使用不同的背景，或 bKGD 块缺失，则查看器可能应忽略该调色板。查看器可以在不同于其原意的背景下使用建议调色板，但结果可能不佳。
如果查看器将透明的 truecolor 图像呈现在比统一颜色更复杂的背景上，则建议调色板很可能不会对合成（composite）图像达到最优。在这种情况下，最好对 truecolor PNG 图像和背景图像先执行一次
truecolor 合成步骤，然后对合成结果进行颜色量化。
在 truecolor PNG 数据流中，如果同时出现 PLTE 和
sPLT 块，PNG 解码器可以在两者建议的调色板之间进行选择，但应注意上文所述的不同透明语义。
sPLT 与 hIST 块中的频率信息在查看器不能提供与 PNG
数据流中调色板相同数量颜色时很有用。如果查看器仅缺少少数颜色，通常将使用频率最低的颜色从调色板中删除即可。要大幅减少颜色数量，最好选择全新的代表颜色，而不是试图使用现有调色板的子集。这等同于执行一次新的颜色量化步骤；不过现有的调色板和直方图可以作为输入数据，从而避免对
IDAT 块中的 image data 进行扫描。
如果未提供建议调色板，解码器可以自行生成，不过需要对 IDAT 块中的 image data
做一次额外遍历。或者，也可以使用一个默认调色板（可能是一个色彩立方体）。
另见 12.5 建议调色板。
