码迷,mamicode.com
首页 > 其他好文 > 详细

PNG文件格式具体解释

时间:2014-10-12 20:13:18      阅读:326      评论:0      收藏:0      [点我收藏+]

标签:style   blog   http   color   io   os   使用   ar   java   

 

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,bubuko.com,布布扣为了方便大家观看,我们将图像放大:

bubuko.com,布布扣

使用UltraEdit32打开该文件,例如以下:
00000000~00000007:

bubuko.com,布布扣

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

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

00000008~00000020:

bubuko.com,布布扣

  • 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:

bubuko.com,布布扣

可选数据块sBIT,颜色採样率,RGB都是256(2^8=256)

00000030~00000062:

bubuko.com,布布扣

这里是调色板信息

  • 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:

bubuko.com,布布扣

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

000000C0~000000F8:

bubuko.com,布布扣

以上选中部分是IDAT数据块

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

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

000000F9~00000104:

bubuko.com,布布扣

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

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

至此,我们已经能够从一个PNG文件里识别出各个数据块了。因为PNG中规定除重要数据块外,其他的辅助数据块都为可选部分,因此,有了这个标准后,我们能够通过删除全部的辅助数据块来降低PNG文件的大小。(当然,须要注意的是,PNG格式能够保存图像中的层、文字等信息,一旦删除了这些辅助数据块后,图像将失去原来的可编辑性。)

bubuko.com,布布扣

删除了辅助数据块后的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色),因此,对于图片的映射能够例如以下:

bubuko.com,布布扣
(调色板对比图)

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文件了,如图:

bubuko.com,布布扣
(选中的部分为生成的“压缩”数据)

至此,我们已经可以採用最快的时间将数组转换为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文件格式具体解释

标签:style   blog   http   color   io   os   使用   ar   java   

原文地址:http://www.cnblogs.com/yxwkf/p/4020823.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!