PNG文件结构分析

http://blog.csdn.net/bisword/archive/2008/08/06/2777121.aspx

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

 

前言

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

PNG的文件结构

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

十进制数	137 80 78 71 13 10 26 10
十六进制数	89 50 4E 47 0D 0A 1A 0A

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

PNG文件标志

PNG数据块

……

PNG数据块

PNG数据块（Chunk）

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

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

PNG文件格式中的数据块
数据块符号	数据块名称	多数据块	可选否	位置限制
IHDR	文件头数据块	否	否	第一块
cHRM	基色和白色点数据块	否	是	在PLTE和IDAT之前
gAMA	图像γ数据块	否	是	在PLTE和IDAT之前
sBIT	样本有效位数据块	否	是	在PLTE和IDAT之前
PLTE	调色板数据块	否	是	在IDAT之前
bKGD	背景颜色数据块	否	是	在PLTE之后IDAT之前
hIST	图像直方图数据块	否	是	在PLTE之后IDAT之前
tRNS	图像透明数据块	否	是	在PLTE之后IDAT之前
oFFs	(专用公共数据块)	否	是	在IDAT之前
pHYs	物理像素尺寸数据块	否	是	在IDAT之前
sCAL	(专用公共数据块)	否	是	在IDAT之前
IDAT	图像数据块	是	否	与其他IDAT连续
tIME	图像最后修改时间数据块	否	是	无限制
tEXt	文本信息数据块	是	是	无限制
zTXt	压缩文本数据块	是	是	无限制
fRAc	(专用公共数据块)	是	是	无限制
gIFg	(专用公共数据块)	是	是	无限制
gIFt	(专用公共数据块)	是	是	无限制
gIFx	(专用公共数据块)	是	是	无限制
IEND	图像结束数据	否	否	最后一个数据块

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

数据块结构

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

名称	字节数	说明
Length (长度)	4字节	指定数据块中数据域的长度，其长度不超过(231－1)字节
Chunk Type Code (数据块类型码)	4字节	数据块类型码由ASCII字母(A-Z和a-z)组成
Chunk Data (数据块数据)	可变长度	存储按照Chunk Type Code指定的数据
CRC (循环冗余检测)	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字节组成，它的格式如下表所示。

域的名称	字节数	说明
Width	4 bytes	图像宽度，以像素为单位
Height	4 bytes	图像高度，以像素为单位
Bit depth	1 byte	图像深度： 索引彩色图像：1，2，4或8 灰度图像：1，2，4，8或16 真彩色图像：8或16
ColorType	1 byte	颜色类型： 0：灰度图像, 1，2，4，8或16 2：真彩色图像，8或16 3：索引彩色图像，1，2，4或8 4：带α通道数据的灰度图像，8或16 6：带α通道数据的真彩色图像，8或16
Compression method	1 byte	压缩方法(LZ77派生算法)
Filter method	1 byte	滤波器方法
Interlace method	1 byte	隔行扫描方法： 0：非隔行扫描 1： Adam7(由Adam M. Costello开发的7遍隔行扫描方法)

由于我们研究的是手机上的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个字节组成：

颜色	字节	意义
Red	1 byte	0 = 黑色, 255 = 红
Green	1 byte	0 = 黑色, 255 = 绿色
Blue	1 byte	0 = 黑色, 255 = 蓝色

因此，调色板的长度应该是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文件)

(已阅读 < src="../../Manager/Counter.asp?id=20&inc=true"> 次)

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

(由于IHDR、PLTE的结构都非常简单，因此，这里我们只是重点讲一讲IDAT的生成方法，IHDR和PLTE的数据内容都沿用以上的数据内容)

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

(调色板对照图)

12	11	10	9	8	7	6	5
11	10	9	8	7	6	5	4
10	9	8	7	6	5	4	3
9	8	7	6	5	4	3	2
8	7	6	5	4	3	2	1
7	6	5	4	3	2	1	0
6	5	4	3	2	1	0	0
5	4	3	2	1	0	0	0

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

0	12	11	10	9	8	7	6	5
0	11	10	9	8	7	6	5	4
0	10	9	8	7	6	5	4	3
0	9	8	7	6	5	4	3	2
0	8	7	6	5	4	3	2	1
0	7	6	5	4	3	2	1	0
0	6	5	4	3	2	1	0	0
0	5	4	3	2	1	0	0	0

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

0	203	169	135	101
0	186	152	118	84
0	169	135	101	67
0	152	118	84	50
0	135	101	67	33
0	118	84	50	16
0	101	67	33	0
0	84	50	16	0

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

然而，事情并不是这么简单，因为我们研究的是手机上的PNG，如果需要在手机上完成LZ77压缩工作，消耗的时间是可想而知的，因此，我们得再想办法加减少压缩时消耗的时间。

好在LZ77也提供了无压缩的压缩方法（奇怪吧？），因此，我们只需要简单的使用无压缩的方式写入数据就可以了，这样虽然浪费了空间，却换回了时间！

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

字节	意义
0~2	压缩信息，固定为0x78, 0xda, 0x1
3~6	压缩块的LEN和NLEN信息
压缩的数据
最后4字节	Adler32信息

其中的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文件署名域

　　8字节的PNG文件署名域用来识别该文件是不是PNG文件。该域的值是：

　　十进制数 137 80 78 71 13 10 26 10

　　十六进制数 89 50 4e 47 0d 0a 1a 0a

/

　GIF图像文件是以块的形式来存储图像信息，其中的块又称为区域结构。按照其中块的特征又可以将所有的块分成三大类，分别是控制块（Control Block）、图像描述块（Graphic Rendering Block）和特殊用途块（Special Purpose Block）。控制块包含了控制数据流的处理以及硬件参数的设置，其成员主要包括文件头信息、逻辑屏幕描述块、图像控制扩充块和文件结尾块。图像描述块包含了在显示设备上描述图像所需的信息，其成员包括图像描述块、全局调色板、局部调色板、图像压缩数据和图像说明扩充块。特殊用途块包含了与图像数据处理无直接关系的信息，其成员包括图像注释扩充块和应用程序扩充块。下面详细介绍每一个块的详细结构。

　　1. 文件头信息

　　GIF的文件头只有六个字节，其结构定义如下：

　　typedef struct gifheader

　　{

　　BYTE bySignature[3];

　　BYTE byVersion[3];

　　} GIFHEADER;

　　其中，bySignature为GIF文件标示码，其固定值为“GIF”，使用者可以通过该域来判断一个图像文件是否是GIF图像格式的文件。byVersion表明GIF文件的版本信息。其取值固定为“87a”和“89a”。分别表示GIF文件的版本为GIF87a或GIF89a。这两个版本有一些不同，GIF87a公布的时间为1987年，该版本不支持动画和一些扩展属性。GIF89a是1989年确定的一个版本标准，只有89a版本才支持动画、注释扩展和文本扩展。

/

http://blog.csdn.net/astrohero/archive/2006/04/25/677394.aspx

JPEG的文件格式

JPEG文件大体上可以分成以下两个部分：标记码(Tag)加压缩数据。先介绍标记码部分。

标记码部分给出了JPEG图象的所有信息(有点类似于BMP中的头信息，但要复杂的多)，如图象的宽、高、Huffman表、量化表等等。标记码有很多，但绝大多数的JPEG文件只包含几种。标记码的结构为：

SOI

DQT

             DRI

                    SOF0

                           DHT

                                  SOS

                                  …

                                  EOI

标记码由两个字节组成，高字节为0XFF，每个标记码之前可以填上个数不限的填充字节0XFF。

下面介绍一些常用的标记码的结构及其含义。

(1)SOI(Start of Image)

标记结构      字节数

0XFF             1

0XD8             1

可作为JPEG格式的判据(JFIF还需要APP0的配合)

(2)APP0(Application)

标记结构       字节数    意义

0XFF             1

0XE0             1

Lp                 2            APP0标记码长度，不包括前两个字节0XFF，0XE0

Identifier 5            JFIF识别码 0X4A，0X46，0X49，0X46，0X00

Version           2            JFIF版本号 可为0X0101或者0X0102

Units              1            单位，等于零时表示未指定，为1表示英寸，为2表示

厘米

Xdensity  2            水平分辨率

Ydensity  2            垂直分辨率

Xthumbnail     1            水平点数

Ythumbnail     1            垂直点数

RGB0             3            RGB的值

RGB1             3            RGB的值

…

RGBn             3            RGB的值，n=Xthumbnail*Ythumbnail

APP0是JPEG保留给Application所使用的标记码，而JFIF将文件的相关信息定义在此标记中。

 

 

其他资料

libpng的使用

2010-02-20 20:56

1. PNG文件格式 PNG图像格式文件(或者称为数据流)由一个8字节的PNG文件署名(PNG file signature)域和按照特定结构组织的3个以上的数据块(chunk)组成。 PNG定义了两种类型的数据块，一种是称为关键数据块(critical chunk)，这是标准的数据块，另一种叫做辅助数据块(ancillary chunks)，这是可选的数据块。关键数据块定义了4个标准数据块，每个PNG文件都必须包含它们，PNG读写软件也都必须要支持这些数据块。虽然PNG文件规范没有要求PNG编译码器对可选数据块进行编码和译码，但规范提倡支持可选数据块。 4个标准数据块： （1）文件头数据块IHDR(header chunk)：它包含有PNG文件中存储的图像数据的基本信息，并要作为第一个数据块出现在PNG数据流中，而且一个PNG数据流中只能有一个文件头数据块。文件头数据块由13字节组成。 域的名称 字节数 说明 Width 4 bytes 图像宽度，以像素为单位 Height 4 bytes 图像高度，以像素为单位 Bit depth 1 byte 图像深度： 索引彩色图像：1，2，4或8 灰度图像：1，2，4，8或16 真彩色图像：8或16 ColorType 1 byte 颜色类型： 0：灰度图像, 1，2，4，8或16 2：真彩色图像，8或16 3：索引彩色图像，1，2，4或8 4：带α通道数据的灰度图像，8或16 6：带α通道数据的真彩色图像，8或16 Compression method 1 byte 压缩方法(LZ77派生算法) Filter method 1 byte 滤波器方法 Interlace method 1 byte 隔行扫描方法： 0：非隔行扫描 1： Adam7(由Adam M. Costello开发的7 遍隔行扫描方法) (2) 调色板数据块PLTE(palette chunk)：它包含有与索引彩色图像((indexed-color image))相关的彩色变换数据，它仅与索引彩色图像有关，而且要放在图像数据块(image data chunk)之前。真彩色的PNG数据流也可以有调色板数据块，目的是便于非真彩色显示程序用它来量化图像数据，从而显示该图像。 表6-09 调色板数据块结构 域的名称 字节数 说明 Red 1 byte 0 = 黑，255 = 红 Green "> 0 = 黑，255 = 绿 Blue 1 byte 0 = 黑，255 = 蓝 　 调色板实际是一个彩色索引查找表，它的表项数目可以是1～256中的一个数，每个表项有3字节，因此调色板数据块所包含的最大字节数为768。 （3) 图像数据块IDAT(image data chunk)：它存储实际的数据，在数据流中可包含多个连续顺序的图像数据块。 (4) 图像结束数据IEND(image trailer chunk)：它用来标记PNG文件或者数据流已经结束，并且必须要放在文件的尾部。 除了表示数据块开始的IHDR必须放在最前面， 表示PNG文件结束的IEND数据块放在最后面之外，其他数据块的存放顺序没有限制。   PNG的IDAT使用从LZ77派生的无损数据压缩算法，大概意思就是将数据作为一个数组，进行字符串匹配 ，从0开始向后移动，在每个位置上都寻找它前面的区域中和当前位置开始的串至少三个相匹配的串，并从这些串中找到最长的匹配的串。然后将会被一个<匹配长度,到匹配串开头的距离>对替换。　 所以解析IDAT就是关键了。　 这里LIBPNG用的是zlib程序库作为压缩引擎。zlib可以从它的官方网站下载。 zlib 的使用在sourceproject可以下载个例子看看：） 那里有显示的例子     Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=1838572     2. libpng libpng是一个跨平台的png解码库，方便易用。我这里不说它怎么移植，基本上如果是支持fopen之类函数的平台都可以支持。其实他的移植非常简单，zlib可能麻烦一点，但相信一般人都能搞定。主要是文件读写和错误处理的试配。 这里只提供一个使用libpng得到文件RGB(A)数据的例子: #include "png.h" #include <stdio.h> #include <stdlib.h> #include <fcntl.h> #include <linux/fb.h> #include <sys/types.h> #include <sys/stat.h> #include <sys/mman.h> #define    FB_DEV  "/dev/fb0" /***************** function declaration ******************/ void            usage(char *msg); int             fb_open(char *fb_device); int             fb_close(int fd); int             fb_stat(int fd, int *width, int *height, int *depth); void           *fb_mmap(int fd, unsigned int screensize); int             fb_munmap(void *start, size_t length); int             fb_pixel(void *fbmem, int width, int height,int x, int y, unsigned short color); unsigned short RGB888toRGB565(unsigned char red, unsigned char green, unsigned char blue); /************ function implementation ********************/ int main(int argc, char *argv[]) {    /*png变量定义*/    png_structp png_ptr;    png_infop info_ptr;    unsigned int sig_read = 0;    png_uint_32 width, height;    int bit_depth, color_type, interlace_type;    unsigned char *buffer;    int pos=0;    char* name="./background.png";    FILE           *infile;    int i,j;    int m_width;    int m_height;    int size;    unsigned short  color;    /*    * declaration for framebuffer device    */       int             fbdev;    char           *fb_device;    unsigned char  *fbmem;    unsigned int    screensize;    unsigned int    fb_width;    unsigned int    fb_height;    unsigned int    fb_depth;    unsigned int    x;    unsigned int    y;    fbdev = fb_open(fb_device);    fb_stat(fbdev, &fb_width, &fb_height, &fb_depth);          screensize = fb_width * fb_height * fb_depth / 8;    fbmem = fb_mmap(fbdev, screensize);    /*    * open input png file    */ FILE* file = fopen(argv[1], "rb"); png_ptr = png_create_read_struct(PNG_LIBPNG_VER_STRING, 0, 0, 0); info_ptr = png_create_info_struct(png_ptr); setjmp(png_jmpbuf(png_ptr)); // 这句很重要 png_init_io(png_ptr, file); // 读文件了 png_read_png(png_ptr, info_ptr, PNG_TRANSFORM_EXPAND, 0); // 得到文件的宽高色深 //m_width = png_get_image_width(png_ptr, info_ptr); //m_height = png_get_image_height(png_ptr, info_ptr); //color_type = png_get_color_type(png_ptr, info_ptr); png_get_IHDR(png_ptr, info_ptr, &m_width, &m_height, &bit_depth, &color_type,NULL, NULL, NULL); printf("withd:%d height:%d colortype:%d bit_depth:%d/n ",m_width,m_height,color_type,bit_depth);//只处理真彩色图像 size = m_height * m_width * 3;//图片占据的存储空间 buffer = (unsigned char *) malloc(m_width*3);//一行需要的存储空间 width*channels*bitdepth/8  其中channels=3 bitdepth/8=1 // row_pointers里边就是传说中的rgba数据了 png_bytep* row_pointers = png_get_rows(png_ptr, info_ptr); // 拷贝！！注意，如果你读取的png没有A通道，就要3位3位的读。还有就是注意字节对其的问题，最简单的就是别用不能被4整除的宽度就行了。不过你实在想用，就要在这里加上相关的对齐处理。 i=j=0; for(i = 0; i < m_height; i++) {    pos=0;    for(j = 0; j < m_width; j += 1)    {     /*读取一行数据*/     buffer[pos++] = row_pointers[i][j*3];   // red     buffer[pos++] = row_pointers[i][j*3 + 1]; // green     buffer[pos++] = row_pointers[i][j*3+2]; // blue       }   /*转换并显示一行数据*/   for (j = 0; j < m_width; j++)   {      color = RGB888toRGB565(buffer[j * 3],      buffer[j * 3 + 1], buffer[j * 3 + 2]);     fb_pixel(fbmem, fb_width, fb_height, j, i, color);   } }   png_destroy_read_struct(&png_ptr, &info_ptr, 0); fclose(file);   fb_munmap(fbmem, screensize);              fb_close(fbdev); return 0; }   int fb_open(char *fb_device) {        int             fd;        if ((fd = open("/dev/fb0", O_RDWR)) < 0) {               perror(__func__);               return (-1);        }        return (fd); } /*  * get framebuffer's width,height,and depth.  * return 0 if success, else return -1.  */ int fb_stat(int fd, int *width, int *height, int *depth) {        struct fb_fix_screeninfo fb_finfo;        struct fb_var_screeninfo fb_vinfo;        if (ioctl(fd, FBIOGET_FSCREENINFO, &fb_finfo)) {               perror(__func__);               return (-1);        }        if (ioctl(fd, FBIOGET_VSCREENINFO, &fb_vinfo)) {               perror(__func__);               return (-1);        }        *width = fb_vinfo.xres;        *height = fb_vinfo.yres;        *depth = fb_vinfo.bits_per_pixel;        return (0); } /*  * map shared memory to framebuffer device.  * return maped memory if success,  * else return -1, as mmap dose.  */ void           * fb_mmap(int fd, unsigned int screensize) {        caddr_t         fbmem;        if ((fbmem = mmap(0, screensize, PROT_READ | PROT_WRITE,                                      MAP_SHARED, fd, 0)) == MAP_FAILED) {               perror(__func__);               return (void *) (-1);        }        return (fbmem); } /*  * unmap map memory for framebuffer device.  */ int fb_munmap(void *start, size_t length) {        return (munmap(start, length)); } /*  * close framebuffer device  */ int fb_close(int fd) {        return (close(fd)); } /*  * display a pixel on the framebuffer device.  * fbmem is the starting memory of framebuffer,  * width and height are dimension of framebuffer,  * x and y are the coordinates to display,  * color is the pixel's color value.  * return 0 if success, otherwise return -1.  */ int fb_pixel(void *fbmem, int width, int height,                int x, int y, unsigned short color) {        if ((x > width) || (y > height))               return (-1);        unsigned short *dst = ((unsigned short *) fbmem + y * width + x);        *dst = color;        return (0); } unsigned short RGB888toRGB565(unsigned char red, unsigned char green, unsigned char blue) {        unsigned short  B = (blue >> 3) & 0x001F;        unsigned short  G = ((green >> 2) << 5) & 0x07E0;        unsigned short  R = ((red >> 3) << 11) & 0xF800;        return (unsigned short) (R | G | B); }