PNG文件格式具体解释

PNG文件结构分析(上：了解PNG文件存储格式)

前言

我们都知道，在进行J2ME的手机应用程序开发的时候，在图片的使用上，我们能够使用PNG格式的图片（甚至于在有的手机上，我们仅仅能够使用PNG格式的图片），虽然使用图片能够为我们的应用程序添加不少亮点，然而，仅仅支持PNG格式的图片却又限制了我们进一步发挥的可能性（事实上，应该说是因为手机平台上的处理能力有限）。 在MIDP2中，或者某些厂商（如NOKIA）提供的API中，提供了drawPixels/getPixels的方法，这些方法进一步提高了开发人员处理图片的灵活性，然而，在MIDP2还未全然普及的今天，我们须要在MIDP1 .0中实现这类方法还属于异想天开，因此，为了实现更高级的应用，我们必须充分挖掘PNG的潜力。

PNG的文件结构

对于一个PNG文件来说，其文件头总是由位固定的字节来描写叙述的：

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

PNG数据块（Chunk）

PNG定义了两种类型的数据块，一种是称为重要数据块(critical chunk)，这是标准的数据块，还有一种叫做辅助数据块(ancillary chunks)，这是可选的数据块。重要数据块定义了4个标准数据块，每一个PNG文件都必须包括它们，PNG读写软件也都必需要支持这些数据块。尽管PNG文件规范没有要求PNG编译码器对可选数据块进行编码和译码，但规范提倡支持可选数据块。

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

为了简单起见，我们如果在我们使用的PNG文件里，这4个数据块按以上先后顺序进行存储，而且都仅仅出现一次。

数据块结构

PNG文件里，每一个数据块由4个部分组成，例如以下：

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图片，然而，实际上，假设一个图片过大，会因为内存耗尽而无法读取。
  
• 颜色类型：全部颜色类型都有被支持，尽管这些颜色的显示依赖于实际设备的显示能力。同一时候，MIDP也能支持alpha通道，可是，全部的alpha通道信息都会被忽略而且当作不透明的颜色对待。
  
• 色深：全部的色深都能被支持。
  
• 压缩方法：仅支持压缩方式0（deflate压缩方式），这和jar文件的压缩方式全然同样，所以，PNG图片数据的解压和jar文件的解压能够使用同样的代码。（事实上这也就是为什么J2ME能非常好的支持PNG图像的原因：））
  
• 滤波器方法：虽然在PNG的白皮书中仅定义了方法0，然而全部的5种方法都被支持！
  
• 隔行扫描：尽管MIDP支持0、1两种方式，然而，当使用隔行扫描时，MIDP却不会真正的使用隔行扫描方式来显示。
  
• PLTE chunk：支持
  
• IDAT chunk：图像信息必须使用5种过滤方式中的方式0 (None, Sub, Up, Average, Paeth)
  
• IEND chunk：当IEND数据块被找到时，这个PNG图像才觉得是合法的PNG图像。
  
• 可选数据块：MIDP能够支持下列辅助数据块，然而，这却不是必须的。
  

  bKGD cHRM gAMA hIST iCCP iTXt pHYs
  sBIT sPLT sRGB tEXt tIME tRNS zTXt

关于很多其它的信息，能够參考http://www.w3.org/TR/REC-png.html

PLTE

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

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

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

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

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

IDAT

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

IDAT存放着图像真正的数据信息，因此，假设可以了解IDAT的结构，我们就行非常方便的生成PNG图像。

IEND

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

假设我们细致观察PNG文件，我们会发现，文件的结尾12个字符看起来总应该是这种：

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

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

实例研究PNG

下面是由Fireworks生成的一幅图像，图像大小为8*8，为了方便大家观看，我们将图像放大：

使用UltraEdit32打开该文件，例如以下：
00000000~00000007：

能够看到，选中的头8个字节即为PNG文件的标识。

接下来的地方就是IHDR数据块了：

00000008~00000020：

• 00 00 00 0D 说明IHDR头块长为13
  
• 49 48 44 52 IHDR标识
  
• 00 00 00 08 图像的宽，8像素
  
• 00 00 00 08 图像的高，8像素
  
• 04 色深，2^4=16，即这是一个16色的图像（也有可能颜色数不超过16，当然，假设颜色数不超过8，用03表示更合适）
  
• 03 颜色类型，索引图像
  
• 00 PNG Spec规定此处总为0（非0值为将来使用更好的压缩方法预留），表示使压缩方法(LZ77派生算法)
  
• 00 同上
  
• 00 非隔行扫描
  
• 36 21 A3 B8 CRC校验

00000021~0000002F：

可选数据块sBIT，颜色採样率，RGB都是256（2^8=256）

00000030~00000062：

这里是调色板信息

• 00 00 00 27 说明调色板数据长为39字节，既13个颜色数
  
• 50 4C 54 45 PLTE标识
  
• FF FF 00 颜色0
  
• FF ED 00 颜色1
  
• …… ……
  
• 09 00 B2 最后一个颜色，12
  
• 5F F5 BB DD CRC校验

00000063~000000C5：

这部分包括了pHYs、tExt两种类型的数据块共3块，因为并不太重要，因此也不再具体描写叙述了。

000000C0~000000F8：

以上选中部分是IDAT数据块

• 00 00 00 27 数据长为39字节
  
• 49 44 41 54 IDAT标识
  
• 78 9C…… 压缩的数据，LZ77派生压缩方法
  
• DA 12 06 A5 CRC校验

IDAT中压缩数据部分在后面会有具体的介绍。

000000F9~00000104：

IEND数据块，这部分正如上所说，通常都应该是

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

至此，我们已经能够从一个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实现有兴趣，能够參考下面两个网站：

• http://jazzlib.sourceforge.net/
  
• http://www.jcraft.com/jzlib/index.html

PNG文件结构分析(下：在手机上生成PNG文件)

(已阅读

次)

上面我们已经对PNG的存储格式有了了解，因此，生成PNG图片仅仅须要依照以上的数据块写入文件就可以。

(因为IHDR、PLTE的结构都很easy，因此，这里我们仅仅是重点讲一讲IDAT的生成方法，IHDR和PLTE的数据内容都沿用以上的数据内容)

问题确实是这种，我们知道，对于大多数的图形文件来说，我们都能够将实际的图像内容映射为一个二维的颜色数组，对于上面的PNG文件，因为它用的是16色的调色板（实际是13色），因此，对于图片的映射能够例如以下：

(调色板对比图)

PNG Spec中指出，假设PNG文件不是採用隔行扫描方法存储的话，那么，数据是依照行(ScanLine)来存储的，为了区分第一行，PNG规定在每一行的前面加上0以示区分，因此，上面的图像映射应该例如以下：

另外，须要注意的是，因为PNG在存储图像时为了节省空间，因此每一行是依照位(Bit)来存储的，而并非我们想象的字节（Byte），假设你没有忘记的话，我们的IHDR数据块中的色深就指明了这一点，所以，为了凑成PNG所须要的IDAT，我们的数据得改成例如以下：

最后，我们对这些数据进行LZ77压缩就能够得到IDAT的正确内容了。

然而，事情并非这么简单，由于我们研究的是手机上的PNG，假设须要在手机上完毕LZ77压缩工作，消耗的时间是可想而知的，因此，我们得再想办法加降低压缩时消耗的时间。

好在LZ77也提供了无压缩的压缩方法（奇怪吧？），因此，我们仅仅须要简单的使用无压缩的方式写入数据就能够了，这样尽管浪费了空间，却换回了时间！

好了，让我们看一看怎么样凑成无压缩的LZ77压缩块：

当中的LEN是指数据的长度，占用两个字节，对于我们的图像来说，第一个Scan Line包括了5个字节（如第一行的0, 203, 169, 135, 101），所以LEN的值为5（字节/行） * 8（行） = 40（字节），生成字节为28 00（低字节在前），NLEN是LEN的补码，即NLEN = LEN ^ 0xFFFF，所以NLEN的为 D7 FF，Adler32信息为24 A7 0B A4（详细算法见源程序），因此，依照这种顺序，我们生成IDAT数据块，最后，我们将IHDR、PLTE、IDAT和IEND数据块写入文件里，就能够得到PNG文件了，如图：

（选中的部分为生成的“压缩”数据）

至此，我们已经可以採用最快的时间将数组转换为PNG图片了。

參考资料：

PNG文件格式白皮书：http://www.w3.org/TR/REC-png.html
为数不多的中文PNG格式说明：http://dev.gameres.com/Program/Visual/Other/PNGFormat.htm
RFC-1950(ZLIB Compressed Data Format Specification)：ftp://ds.internic.net/rfc/rfc1950.txt
RFC-1950(DEFLATE Compressed Data Format Specification)：ftp://ds.internic.net/rfc/rfc1951.txt
LZ77算法的JAVA实现：http://jazzlib.sourceforge.net/
LZ77算法的JAVA实现，包含J2ME版本号：http://www.jcraft.com/jzlib/index.html

PNG文件格式具体解释,布布扣,bubuko.com