大家好,又见面了,我是全栈君,祝每个程序员都可以多学几门语言。
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码生成多项式进行计算:
x32+x26+x23+x22+x16+x12+x11+x10+x8+x7+x5+x4+x2+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实现有兴趣,能够參考下面两个网站:
PNG文件结构分析(下:在手机上生成PNG文件)
(已阅读 次)
上面我们已经对PNG的存储格式有了了解,因此,生成PNG图片仅仅须要依照以上的数据块写入文件就可以。
(因为IHDR、PLTE的结构都很easy,因此,这里我们仅仅是重点讲一讲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
发布者:全栈程序员-用户IM,转载请注明出处:https://javaforall.cn/118300.html原文链接:https://javaforall.cn
【正版授权,激活自己账号】: Jetbrains全家桶Ide使用,1年售后保障,每天仅需1毛
【官方授权 正版激活】: 官方授权 正版激活 支持Jetbrains家族下所有IDE 使用个人JB账号...