PNG文件结构分析.docx
- 文档编号:8001759
- 上传时间:2023-01-27
- 格式:DOCX
- 页数:15
- 大小:120.21KB
PNG文件结构分析.docx
《PNG文件结构分析.docx》由会员分享,可在线阅读,更多相关《PNG文件结构分析.docx(15页珍藏版)》请在冰豆网上搜索。
PNG文件结构分析
PNG文件结构分析之一(了解PNG文件存储格式)
作者:
leftmoon 文章来源:
点击数:
16570 更新时间:
2005-4-13
前言
我们都知道,在进行J2ME的手机应用程序开发的时候,在图片的使用上,我们可以使用PNG格式的图片(甚至于在有的手机上,我们只可以使用PNG格式的图片),尽管使用图片可以为我们的应用程序增加不少亮点,然而,只支持PNG格式的图片却又限制了我们进一步发挥的可能性(其实,应该说是由于手机平台上的处理能力有限)。
在MIDP2中,或者某些厂商(如NOKIA)提供的API中,提供了drawPixels/getPixels的方法,这些方法进一步提高了开发者处理图片的灵活性,然而,在MIDP2还未完全普及的今天,我们需要在MIDP1.0中实现这类方法还属于异想天开,因此,为了实现更高级的应用,我们必须充分挖掘PNG的潜力。
PNG的文件结构
对于一个PNG文件来说,其文件头总是由位固定的字节来描述的:
十进制数
13780787113102610
十六进制数
89504E470D0A1A0A
其中第一个字节0x89超出了ASCII字符的范围,这是为了避免某些软件将PNG文件当做文本文件来处理。
文件中剩余的部分由3个以上的PNG的数据块(Chunk)按照特定的顺序组成,因此,一个标准的PNG文件结构应该如下:
PNG文件标志
PNG数据块
……
PNG数据块
PNG数据块(Chunk)
PNG定义了两种类型的数据块,一种是称为关键数据块(criticalchunk),这是标准的数据块,另一种叫做辅助数据块(ancillarychunks),这是可选的数据块。
关键数据块定义了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)字节
ChunkTypeCode(数据块类型码)
4字节
数据块类型码由ASCII字母(A-Z和a-z)组成
ChunkData(数据块数据)
可变长度
存储按照ChunkTypeCode指定的数据
CRC(循环冗余检测)
4字节
存储用来检测是否有错误的循环冗余码
CRC(cyclicredundancycheck)域中的值是对ChunkTypeCode域和ChunkData域中的数据进行计算得到的。
CRC具体算法定义在ISO3309和ITU-TV.42中,其值按下面的CRC码生成多项式进行计算:
x32+x26+x23+x22+x16+x12+x11+x10+x8+x7+x5+x4+x2+x+1
下面,我们依次来了解一下各个关键数据块的结构吧。
IHDR
文件头数据块IHDR(headerchunk):
它包含有PNG文件中存储的图像数据的基本信息,并要作为第一个数据块出现在PNG数据流中,而且一个PNG数据流中只能有一个文件头数据块。
文件头数据块由13字节组成,它的格式如下表所示。
域的名称
字节数
说明
Width
4bytes
图像宽度,以像素为单位
Height
4bytes
图像高度,以像素为单位
Bitdepth
1byte
图像深度:
索引彩色图像:
1,2,4或8
灰度图像:
1,2,4,8或16
真彩色图像:
8或16
ColorType
1byte
颜色类型:
0:
灰度图像,1,2,4,8或16
2:
真彩色图像,8或16
3:
索引彩色图像,1,2,4或8
4:
带α通道数据的灰度图像,8或16
6:
带α通道数据的真彩色图像,8或16
Compressionmethod
1byte
压缩方法(LZ77派生算法)
Filtermethod
1byte
滤波器方法
Interlacemethod
1byte
隔行扫描方法:
0:
非隔行扫描
1:
Adam7(由AdamM.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却不会真正的使用隔行扫描方式来显示。
∙PLTEchunk:
支持
∙IDATchunk:
图像信息必须使用5种过滤方式中的方式0(None,Sub,Up,Average,Paeth)
∙IENDchunk:
当IEND数据块被找到时,这个PNG图像才认为是合法的PNG图像。
∙可选数据块:
MIDP可以支持下列辅助数据块,然而,这却不是必须的。
bKGDcHRMgAMAhISTiCCPiTXtpHYs
sBITsPLTsRGBtEXttIMEtRNSzTXt
关于更多的信息,可以参考http:
//www.w3.org/TR/REC-png.html
PLTE
调色板数据块PLTE(palettechunk)包含有与索引彩色图像(indexed-colorimage)相关的彩色变换数据,它仅与索引彩色图像有关,而且要放在图像数据块(imagedatachunk)之前。
PLTE数据块是定义图像的调色板信息,PLTE可以包含1~256个调色板信息,每一个调色板信息由3个字节组成:
颜色
字节
意义
Red
1byte
0=黑色,255=红
Green
1byte
0=黑色,255=绿色
Blue
1byte
0=黑色,255=蓝色
因此,调色板的长度应该是3的倍数,否则,这将是一个非法的调色板。
对于索引图像,调色板信息是必须的,调色板的颜色索引从0开始编号,然后是1、2……,调色板的颜色数不能超过色深中规定的颜色数(如图像色深为4的时候,调色板中的颜色数不可以超过2^4=16),否则,这将导致PNG图像不合法。
真彩色图像和带α通道数据的真彩色图像也可以有调色板数据块,目的是便于非真彩色显示程序用它来量化图像数据,从而显示该图像。
IDAT
图像数据块IDAT(imagedatachunk):
它存储实际的数据,在数据流中可包含多个连续顺序的图像数据块。
IDAT存放着图像真正的数据信息,因此,如果能够了解IDAT的结构,我们就可以很方便的生成PNG图像。
IEND
图像结束数据IEND(imagetrailerchunk):
它用来标记PNG文件或者数据流已经结束,并且必须要放在文件的尾部。
如果我们仔细观察PNG文件,我们会发现,文件的结尾12个字符看起来总应该是这样的:
0000000049454E44AE426082
不难明白,由于数据块结构的定义,IEND数据块的长度总是0(00000000,除非人为加入信息),数据标识总是IEND(49454E44),因此,CRC码也总是AE426082。
实例研究PNG
以下是由Fireworks生成的一幅图像,图像大小为8*8,
为了方便大家观看,我们将图像放大:
使用UltraEdit32打开该文件,如下:
00000000~00000007:
可以看到,选中的头8个字节即为PNG文件的标识。
接下来的地方就是IHDR数据块了:
00000008~00000020:
∙0000000D说明IHDR头块长为13
∙49484452IHDR标识
∙00000008图像的宽,8像素
∙00000008图像的高,8像素
∙04色深,2^4=16,即这是一个16色的图像(也有可能颜色数不超过16,当然,如果颜色数不超过8,用03表示更合适)
∙03颜色类型,索引图像
∙00PNGSpec规定此处总为0(非0值为将来使用更好的压缩方法预留),表示使压缩方法(LZ77派生算法)
∙00同上
∙00非隔行扫描
∙3621A3B8CRC校验
00000021~0000002F:
可选数据块sBIT,颜色采样率,RGB都是256(2^8=256)
00000030~00000062:
这里是调色板信息
∙00000027说明调色板数据长为39字节,既13个颜色数
∙504C5445PLTE标识
∙FFFF00颜色0
∙FFED00颜色1
∙…………
∙0900B2最后一个颜色,12
∙5FF5BBDDCRC校验
00000063~000000C5:
这部分包含了pHYs、tExt两种类型的数据块共3块,由于并不太重要,因此也不再详细描述了。
000000C0~000000F8:
以上选中部分是IDAT数据块
∙00000027数据长为39字节
∙49444154IDAT标识
∙789C……压缩的数据,LZ77派生压缩方法
∙DA1206A5CRC校验
IDAT中压缩数据部分在后面会有详细的介绍。
000000F9~00000104:
IEND数据块,这部分正如上所说,通常都应该是
0000000049454E44AE426082
至此,我们已经能够从一个PNG文件中识别出各个数据块了。
由于PNG中规定除关键数据块外,其它的辅助数据块都为可选部分,因此,有了这个标准后,我们可以通过删除所有的辅助数据块来减少PNG文件的大小。
(当然,需要注意的是,PNG格式可以保存图像中的层、文字等信息,一旦删除了这些辅助数据块后,图像将失去原来的可编辑性。
)
删除了辅助数据块后的PNG文件,现在文件大小为147字节,原文件大小为261字节,文件大小减少后,并不影响图像的内容。
其实,我们可以通过改变调色板的色值来完成一些又趣的事情,比如说实现云彩/水波的流动效果,实现图像的淡入淡出效果等等,在此,给出一个链接给大家看也许更直接:
如上说过,IDAT数据块是使用了LZ77压缩算法生成的,由于受限于手机处理器的能力,因此,如果我们在生成IDAT数据块时仍然使用LZ77压缩算法,将会使效率大打折扣,因此,为了效率,只能使用无压缩的LZ77算法,关于LZ77算法的具体实现,此文不打算深究,如果你对LZ77算法的JAVA实现有兴趣,可以参考以下两个站点:
∙
∙
参考资料:
PNG文件格式白皮书:
http:
//www.w3.org/TR/REC-png.html
为数不多的中文PNG格式说明:
RFC-1950(ZLIBCompressedDataFormatSpecification):
ftp:
//
RFC-1950(DEFLATECompressedDataFormatSpecification):
ftp:
//
LZ77算法的JAVA实现:
LZ77算法的JAVA实现,包括J2ME版本:
PNG文件结构分析之二(在手机上生成PNG文件)
作者:
leftmoon 文章来源:
点击数:
6901 更新时间:
2005-4-13
上面我们已经对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
PNGSpec中指出,如果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是指数据的长度,占用两个字节,对于我们的图像来说,第一个ScanLine包含了5个字节(如第一行的0,203,169,135,101),所以LEN的值为5(字节/行)*8(行)=40(字节),生成字节为2800(低字节在前),NLEN是LEN的补码,即NLEN=LEN^0xFFFF,所以NLEN的为D7FF,Adler32信息为24A70BA4(具体算法见源程序),因此,按照这样的顺序,我们生成IDAT数据块,最后,我们将IHDR、PLTE、IDAT和IEND数据块写入文件中,就可以得到PNG文件了,如图:
(选中的部分为生成的“压缩”数据)
至此,我们已经能够采用最快的时间将数组转换为PNG图片了。
生成的PNG文件:
范例(附源程序)
∙有效的减少PNG格式文件的大小
∙通过改变调色板实现类似云彩流动的效果(源程序包含在此jar文件中)
安全高效的使用PNG图
众所周知,J2ME程序使用的最多的图片格式为PNG格式,如何在程序中使用PNG图片对于程序来说有很多的技巧,我将以我的一些经验技巧来讨论有关PNG图片在程序中的应用。
通常情况,一个项目开始的时候策划出了需求,美工出了图片,程序员的代码也开始写了,程序员需要图片时,美工给的图片都为一张张静态的图片,然后通过引擎(或者一些工具)导成程序需要的动画序列,和图片数组,程序在Canvas中把图片数组按照图片序列标志的顺序、位置、桢数表现出来。
动画是组成游戏的非常重要的部分。
因而图片资源的大小、存储方式等对程序生成的jar文件的大小和耗费内存的多少有非常大的影响。
在和J2MEWTK2.2的一些文档中我们可以看到一些关于图片资源如何优化的例子,在此我不予详述,但是提及,重点讲述我们的项目经验。
在一些文档中建议我们把所有的资源都放在一张足够大的PNG图片里面,我们对图片进行分割,这样做有非常大的好处,但是有一些缺点,比如我们把一张大图片读入我们的程序里面的时候,我们在菜单部分仅仅需要和菜单那部分资源,不需要其他的资源,这样我们读出的部分显得就非常的浪费内存,我们可以采取把各种图片资源分别存放到几个大图片中,这样我们需要的时候把需要的部分从jar中读到内存,不需要的时候释放出去,这样可以保证一些运算内存比较小的设备使用很多图片资源,不会发生outofmemory的异常或者错误。
举个例子,一个游戏有菜单、玩游戏、排行榜这样三个部分,完全可以把图片分成三组存储,和菜单相关的存储为menu.png,游戏中的存储为game.png,排行榜需要的图片存储为range.png,我们进入菜单状态只读区menu.png这样程序浪费的内存相当少,进入游戏时先释放掉menu.png占用的资源,再调入game.png。
在项目中这是非常好的应用实例。
在我们的项目中,有时不需要使用切割图像,我们乐于使用一些大小一样的矩形方块状的图片(一些小的公司没有良好的引擎设计时,一般采用这种方式,一些大公司有专门做引擎的e,所以一般采用上面的方法且优化了上面的办法)。
因为一些压缩算法、和图片存储格式等众多原因造成了如下状况:
把很多png图形放到一张png图片里面省更多的空间。
我们如何省空间呢?
答案是:
自己设计一个资源读取器,把需要的所有png图片读取成2进制码并且按照我们能够简单使用的格式写成一个二进制文件,我们只需要在程序中读取这个二进制文件,在把里面的png还原出来即可。
我在我们的项目中发现,单独使用21张14*14的png图像,与巴这21张png重新写成一个二进制文件(不采用任何压缩算法),后者比前者在jar中节省了10KB。
所以说,我们在做游戏的时候,如果没有非常好的引擎,可以采用我们办法来节省空间——把松散的图片用程序写成一个二进制文件,在j2me程序中把这些资源读取出来。
综上,我叙述了两种不同的节省资源的方法,前一种需要比较强大的引擎支持,后一种则不需要,但是后一种确实节省的不如前一种多,但比单纯的用好多png图要节省的多而且不需要复杂的引擎。
在未来,我会继续写一些我们项目中的经验。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- PNG 文件 结构 分析