设为首页收藏本站|繁體中文

Project1

 找回密码
 注册会员
搜索
查看: 5744|回复: 15

[综合信息] PNG文件结构简述(完全版转)

 关闭 [复制链接]

Lv1.梦旅人

梦石
0
星屑
50
在线时间
50 小时
注册时间
2006-11-16
帖子
3409
发表于 2007-1-18 18:24:16 | 显示全部楼层 |阅读模式

加入我们,或者,欢迎回来。

您需要 登录 才可以下载或查看,没有帐号?注册会员

x
原文(包括图片都是直接贴的此处地址):
http://www.ismyway.com/png/png-struct1.htm

这个是在我做pm2refine版图片结构分析的时候,在66搜到一篇文章:
http://rpg.blue/viewthread.php?tid=35524
这个因为排版的太乱,容易看的头昏眼花,于是被直接扔到开水去了……

我在网上搜索了一下,搜到这个的原文出处,所以在这儿贴一下。
因为格式是直接把原文的html代码手动替换成了ubb代码(这样看起来就清爽多了),所以也许会有不小心被替换掉的,看的时候可以对照原文帮忙找一下。
此文没有涉及很多png的内容,只能做导向性的看一下,其实发这个还是因为觉得地球村人气太低的缘故吧,但愿这个不会也被扔去开水…………(当然私下也有希望大家帮忙研究一下的想法)

(如果之后有新的研究成果,原创较多就另外开帖并在此编辑上地址,如果原创较少就直接在后面两个回复中编辑。当然是说“如果”有的话……咳咳…………)

—————————————————正 文—————————————————

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字节 指定数据块中数据域的长度,其长度不超过(2^31-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^32+x^26+x^23+x^22+x^16+x^12+x^11+x^10+x^8+x^7+x^5+x^4+x^2+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文件格式白皮书: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
最近好多想到PM的问题……不会嫌我烦了吧……

Lv1.梦旅人

梦石
0
星屑
50
在线时间
50 小时
注册时间
2006-11-16
帖子
3409
 楼主| 发表于 2007-1-18 18:24:16 | 显示全部楼层 |阅读模式

加入我们,或者,欢迎回来。

您需要 登录 才可以下载或查看,没有帐号?注册会员

x
原文(包括图片都是直接贴的此处地址):
http://www.ismyway.com/png/png-struct1.htm

这个是在我做pm2refine版图片结构分析的时候,在66搜到一篇文章:
http://rpg.blue/viewthread.php?tid=35524
这个因为排版的太乱,容易看的头昏眼花,于是被直接扔到开水去了……

我在网上搜索了一下,搜到这个的原文出处,所以在这儿贴一下。
因为格式是直接把原文的html代码手动替换成了ubb代码(这样看起来就清爽多了),所以也许会有不小心被替换掉的,看的时候可以对照原文帮忙找一下。
此文没有涉及很多png的内容,只能做导向性的看一下,其实发这个还是因为觉得地球村人气太低的缘故吧,但愿这个不会也被扔去开水…………(当然私下也有希望大家帮忙研究一下的想法)

(如果之后有新的研究成果,原创较多就另外开帖并在此编辑上地址,如果原创较少就直接在后面两个回复中编辑。当然是说“如果”有的话……咳咳…………)

—————————————————正 文—————————————————

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字节 指定数据块中数据域的长度,其长度不超过(2^31-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^32+x^26+x^23+x^22+x^16+x^12+x^11+x^10+x^8+x^7+x^5+x^4+x^2+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文件格式白皮书: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
最近好多想到PM的问题……不会嫌我烦了吧……

Lv1.梦旅人

梦石
0
星屑
50
在线时间
50 小时
注册时间
2006-11-16
帖子
3409
 楼主| 发表于 2007-1-18 18:43:31 | 显示全部楼层
奇怪,半个小时前那个站点还能打开的,一会儿又打不开了…………妖怪啊…………

————————————————临时分割线—————————————————
附上我用来研究的一系列图片,地址:
http://rpg.blue/upload_program/files/pm2.rar
其中:
jingling_dat.png:直接从part.dat导出的图。
jingling_dat1.png:在上个文件中去除了tEXt部分后的图。
jingling_acd.PNG:直接在游戏中用windows剪贴板截图后保存为24位色BMP,并在acdsee3.0中切割,再另存为png格式。
jingling_acd1.PNG:上图经过上下翻转以后的图。
jingling_ps.png:直接在游戏中用windows剪贴板截图后保存为24位色BMP,并在photoshop7.0中切割,再另存为ps格式(图片大小、格式和上面两种的差距都很大)

————————————————临时分割线————————————————

这个起初的目的是为了研究pm2refine的图片格式。

pm2refine的图片是直接把一系列的png图片头尾相接拼合起来的,比如在part.dat(除去女孩大图外的所有图)中,按照png文件头:89 50 4E 47来切割文件
(切割文件推荐使用 梁利峰 的文件切割工具“点睛文件分割器 0.90 版”:
http://llf.hanzify.org/llf/show.asp?id=185


分出文件后,可以看到文件是倒置,而且偏色的。(图片看附件中jingling_dat.png)

于是才有了研究的这个念头,不过现在唯一的发现是,把直接截图中切出同样的部分,用acdsee3.0转成png格式后,可以发现和直接导出的png格式大致相同:如直接导出的文件去除了tEXt部分后,和acdsee的对比可以发现,整个文件的大小仅差1字节!而且也都是按照0x2000为一块来分IDAT块,最后剩下的成一块(这个块也仅仅差9个字节!)。所以我觉得之间应该有些关联,或许可以借此研究出pm2refine版偏色的原因…………


(以下有待研究…………)


附件地址:
http://rpg.blue/upload_program/files/pm2.rar
最近好多想到PM的问题……不会嫌我烦了吧……
回复 支持 反对

使用道具 举报

Lv1.梦旅人

梦石
0
星屑
50
在线时间
2 小时
注册时间
2006-9-18
帖子
703
发表于 2007-1-18 18:44:53 | 显示全部楼层
图片是XX
回复 支持 反对

使用道具 举报

Lv1.梦旅人

梦石
0
星屑
50
在线时间
50 小时
注册时间
2006-11-16
帖子
3409
 楼主| 发表于 2007-1-18 18:45:09 | 显示全部楼层
如果有对pm2refine的png格式有进一步研究,放在上一个回复中补充。
此处留空,准备放LZ77压缩算法等png相关知识,或者是对png的其他研究。
(如果以后真的有研究出东西来的话,喵的~)


暂时随手找的一个lz77算法简述:
http://dev.csdn.net/article/19/19582.shtm
全文是各种压缩算法,转的地址(以上是原地址,但是很散——该死的csdn):http://bbs.chinaunix.net/viewthread.php?tid=118507

不过我自己也还没看(晕倒)
最近好多想到PM的问题……不会嫌我烦了吧……
回复 支持 反对

使用道具 举报

Lv1.梦旅人

梦石
0
星屑
50
在线时间
50 小时
注册时间
2006-11-16
帖子
3409
 楼主| 发表于 2007-1-18 18:51:23 | 显示全部楼层
以下引用巫术于2007-1-18 10:44:53的发言:

图片是XX

留空还是速度不够快(哇靠就几秒钟……)

我在第二个回复里面写了,早上10点打开的时候还是可以打开的,然后研究了一会儿,又把代码转成ubb发上来,就发现那个站打不开了…………反正我在本记另存了,到时候真打不开了我就把图片放我自己空间吧…………
反正我也不期望这个帖子有人气,内因和外因都说明这个帖子不会有人气的。发这个只是为了留一个整理笔记,但愿66rpg比我的机器保存的时间还长点吧…………
最近好多想到PM的问题……不会嫌我烦了吧……
回复 支持 反对

使用道具 举报

Lv2.观梦者

梦石
0
星屑
260
在线时间
1373 小时
注册时间
2005-10-16
帖子
5113

贵宾

发表于 2007-1-18 19:18:08 | 显示全部楼层
这个站点就是这样,之前我读完之后告诉别人,别人说找不到网页……

之前还不知道crc算法原来可以通过调用,硬是自己写了一个出来
我只个搬答案的
叔叔我已经当爹了~
婚后闪人了……
回复 支持 反对

使用道具 举报

Lv1.梦旅人

梦石
0
星屑
50
在线时间
50 小时
注册时间
2006-11-16
帖子
3409
 楼主| 发表于 2007-1-18 19:28:07 | 显示全部楼层
ismyway…………
这个站点还是有点意思的(最近在看小白小说的论坛就叫howareyou,哈哈),莫非管理员是火影fans?^_^


看来这个站点还是有点意思的啊…………这次难得两个地方都给我找到“源”了,但是居然图片还是都有点问题(源的用处就是图片,如果图片还坏了,还不如转的,转的起码还会把诸多文给你拼起来,不用一个个找呢)
最近好多想到PM的问题……不会嫌我烦了吧……
回复 支持 反对

使用道具 举报

Lv1.梦旅人

月下可怜人

梦石
0
星屑
50
在线时间
10 小时
注册时间
2005-11-23
帖子
4085

第1届短篇游戏比赛亚军

发表于 2007-1-18 23:41:11 | 显示全部楼层
这个…………
虽然明白说的是A+B=C,但不知道该如何组合在一起…………
纵然千里外,我等雁归来。
回复 支持 反对

使用道具 举报

Lv1.梦旅人

彩色的银子

梦石
0
星屑
50
在线时间
190 小时
注册时间
2006-6-13
帖子
1361

贵宾

发表于 2007-1-19 00:28:30 | 显示全部楼层
-____-同上``完全像在看天书...........
-.-
回复 支持 反对

使用道具 举报

您需要登录后才可以回帖 登录 | 注册会员

本版积分规则

拿上你的纸笔,建造一个属于你的梦想世界,加入吧。
 注册会员
找回密码

站长信箱:[email protected]|手机版|小黑屋|无图版|Project1游戏制作

GMT+8, 2024-3-28 22:56

Powered by Discuz! X3.1

© 2001-2013 Comsenz Inc.

快速回复 返回顶部 返回列表