PNG 文件解读 (2):PNG 格式文件结构与数据结构解读—解码 PNG 数据

zhoulujun

关注

发布于: 12 小时前

PNG 文件识别

之前写过《JPEG/Exif/TIFF格式解读(1):JEPG图片压缩与存储原理分析》，JPEG 文件是以，FFD8 开头，FFD9 结尾，中间存储着以 0xFFE0~0xFFEF 为标志的数据段。

对于一个 PNG 文件来说，其文件头总是由位固定的字节来描述的，HEX： 89 50 4E 47 0D 0A 1A 0A

png文件源码解读

其中第一个字节 0x89 超出了 ASCII 字符的范围，这是为了避免某些软件将 PNG 文件当做文本文件来处理。文件中剩余的部分由 3 个以上的 PNG 的数据块（Chunk）按照特定的顺序组成，因此，一个标准的 PNG 文件结构应该如下：

png文件数据源码数据块分析

与 JPEG 格式如下

jpeg二进制代码示范

何其相似，但却相差甚远。png 数据结构个人觉得比 jpeg 复杂

jpeg：段标识(FF)+段类型(1 字节)+段长度(2 字节)+数据块

png：段长度(4 字节)+段类型/类型标志(4 字节)+数据块+校验码(4 字节)

png 的每一段，称之为数据块。

PNG 数据块（Chunk）

PNG 定义了两种类型的数据块，

关键数据块(critical chunk)，这是标准的数据块
辅助数据块(ancillary chunks)，这是可选的数据块。

关键数据块定义了 4 个标准数据块，每个 PNG 文件都必须包含它们，PNG 读写软件也都必须要支持这些数据块。虽然 PNG 文件规范没有要求 PNG 编译码器对可选数据块进行编码和译码，但规范提倡支持可选数据块。

下表就是 PNG 中数据块的类别，其中，关键数据块部分我们使用深色背景加以区分。

我们目前只需关注标红的关键数据块即可。

数据块中有 4 个关键数据块：

文件头数据块 IHDR（header chunk）：包含有图像基本信息，作为第一个数据块出现并只出现一次。
调色板数据块 PLTE（palette chunk）：必须放在图像数据块之前。
图像数据块 IDAT（image data chunk）：存储实际图像数据。PNG 数据允许包含多个连续的图像数据块。
图像结束数据 IEND（image trailer chunk）：放在文件尾部，表示 PNG 数据流结束。

数据块连起来，大概这个样子：

就是一段段数据按照固定格式填充，头尾必要，中间填充图片的压缩数据。所以解读 png 的所有数据，就需要解读每个数据块

PNG 数据块结构

PNG 文件中，每个数据块由 4 个部分组成，如下：

Length 值的是除：length 本身，Chunk Type Code，CRC 外的长度，也就是 Chunk Data 的长度。
CRC: 一种校验算法。仅仅用来校验数据的正确性的

CRC(cyclic redundancy check)域中的值是对 Chunk Type Code 域和 Chunk Data 域中的数据进行计算得到的。

CRC 具体算法定义在 ISO 3309 和 ITU-T V.42 中，其值按下面的 CRC 码生成多项式进行计算：

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

下面，我们依次来了解一下各个关键数据块的结构吧。

文件头数据块 IHDR

文件头数据块 IHDR(header chunk)：它包含有 PNG 文件中存储的图像数据的基本信息，并要作为第一个数据块出现在 PNG 数据流中，而且一个 PNG 数据流中只能有一个文件头数据块。

文件头数据块由 13 字节组成，它的格式如下表所示。

由于我们研究的是手机上的 PNG，因此，首先我们看看 MIDP1.0 对所使用 PNG 图片的要求吧：

在 MIDP1.0 中，我们只可以使用 1.0 版本的 PNG 图片。并且，所以的 PNG 关键数据块都有特别要求：IHDR
文件大小：MIDP 支持任意大小的 PNG 图片，然而，实际上，如果一个图片过大，会由于内存耗尽而无法读取。
ColorType/颜色类型：所有颜色类型都有被支持，虽然这些颜色的显示依赖于实际设备的显示能力。同时，MIDP 也能支持 alpha 通道，但是，所有的 alpha 通道信息都会被忽略并且当作不透明的颜色对待。
Bit depth/色深：所有的色深都能被支持。
Comdivssion method/压缩方法：仅支持压缩方式 0（deflate 压缩方式），这和 jar 文件的压缩方式完全相同，所以，PNG 图片数据的解压和 jar 文件的解压可以使用相同的代码。（其实这也就是为什么 J2ME 能很好的支持 PNG 图像的原因：））
Filter method/滤波器方法：尽管在 PNG 的白皮书中仅定义了方法 0，然而所有的 5 种方法都被支持！
隔行扫描：虽然 MIDP 支持 0、1 两种方式，然而，当使用隔行扫描时，MIDP 却不会真正的使用隔行扫描方式来显示。
PLTE chunk：支持
IDAT chunk：图像信息必须使用 5 种过滤方式中的方式 0 (None, Sub, Up, Average, Paeth)
IEND chunk：当 IEND 数据块被找到时，这个 PNG 图像才认为是合法的 PNG 图像。
可选数据块：MIDP 可以支持下列辅助数据块，然而，这却不是必须的。

关于更多的信息，可以参考http://www.w3.org/TR/REC-png.html

用十六进制查看器打开一个 PNG 文件:

查看16进制png文件分析IHDR

分析如下：

数据块-调色板数据块 PLTE

调色板数据块 PLTE(palette chunk)包含有与索引彩色图像(indexed-color image)相关的彩色变换数据，它仅与索引彩色图像有关，而且要放在图像数据块(image data chunk)之前。

PLTE 数据块是定义图像的调色板信息，PLTE 可以包含 1~256 个调色板信息，每一个调色板信息由 3 个字节组成：

因此，调色板的长度应该是 3 的倍数，否则，这将是一个非法的调色板。

对于索引图像，调色板信息是必须的，调色板的颜色索引从 0 开始编号，然后是 1、2……，调色板的颜色数不能超过色深中规定的颜色数（如图像色深为 4 的时候，调色板中的颜色数不可以超过 2^4=16），否则，这将导致 PNG 图像不合法。

真彩色图像和带α通道数据的真彩色图像也可以有调色板数据块，目的是便于非真彩色显示程序用它来量化图像数据，从而显示该图像。

用十六进制查看器打开一个索引图像 PNG 文件:

png-indexed-color-hex-plte

分析如下：

预览调色板中的颜色：

indexed-color-plte-colors

pHYs

物理像素数据块，它表示了图片的像素尺寸，或者是高宽比，它的结果如下

unit specifier 的定义如下：

0：unit is unknown
1：unit is the metre

数据块-图像数据块 IDAT

图像数据块 IDAT(image data chunk)：它存储实际的数据，在数据流中可包含多个连续顺序的图像数据块。

IDAT 存放着图像真正的数据信息，因此，如果能够了解 IDAT 的结构，我们就可以很方便的生成 PNG 图像。

用十六进制查看器打开一个索引图像 PNG 文件:

数据块-图像结束数据 IEND

图像结束数据 IEND(image trailer chunk)：它用来标记 PNG 文件或者数据流已经结束，并且必须要放在文件的尾部。

如果我们仔细观察 PNG 文件，我们会发现，文件的结尾 12 个字符看起来总应该是这样的：

00 00 00 00 49 45 4E 44 AE 42 60 82

图像结束数据IEND

不难明白，由于数据块结构的定义，IEND 数据块的长度总是 0（00 00 00 00，除非人为加入信息），数据标识总是 IEND（49 45 4E 44），因此，CRC 码也总是 AE 42 60 82。

IHDR cHRM pHYs IEND

至此，我们已经能够从一个 PNG 文件中识别出各个数据块了。由于 PNG 中规定除关键数据块外，其它的辅助数据块都为可选部分，因此，有了这个标准后，我们可以通过删除所有的辅助数据块来减少 PNG 文件的大小。（当然，需要注意的是，PNG 格式可以保存图像中的层、文字等信息，一旦删除了这些辅助数据块后，图像将失去原来的可编辑性。）

删除了辅助数据块后的 PNG 文件，现在文件大小为 147 字节，原文件大小为 261 字节，文件大小减少后，并不影响图像的内容。

其实，我们可以通过改变调色板的色值来完成一些又趣的事情，比如说实现云彩/水波的流动效果，实现图像的淡入淡出效果等等，在此，给出一个链接给大家看也许更直接：http://blog.csdn.net/flyingghost/archive/2005/01/13/251110.aspx，我写此文也就是受此文的启发的。

如上说过，IDAT 数据块是使用了 LZ77 压缩算法生成的，由于受限于手机处理器的能力，因此，如果我们在生成 IDAT 数据块时仍然使用 LZ77 压缩算法，将会使效率大打折扣，因此，为了效率，只能使用无压缩的 LZ77 算法，关于 LZ77 算法的具体实现，此文不打算深究，如果你对 LZ77 算法的 JAVA 实现有兴趣，可以参考以下两个站点：