PNG图片结构分析与加密和加密-转

阅读次数: 851

  • A+
所属分类:建站

PNG文件格式分为PNG-24和PNG-8,其最大的区别是PNG-24是用24位来保存一个像素值,是真彩色,而PNG-8是用8位索引值来在调色盘 中索引一个颜色,因为一个索引值的最大上限为2的8次方既128,故调色盘中颜色数最多为128种,所以该文件格式又被叫做PNG-8 128仿色。PNG-24因为其图片容量过大,而且在Nokia和Moto等某些机型上创建图片失败和显示不正确等异常时有发生,有时还会严重拖慢显示速度,故并不常 用,CoCoMo认为这些异常和平台底层的图像解压不无关系。不过该格式最大的优点是可以保存Alpha通道,同事也曾有过利用该图片格式实现Alpha 混合的先例,想来随着技术的发展,手机硬件平台的提升,Alpha混合一定会被广泛的应用,到那时该格式的最大优势才会真正发挥

8 bit PNGs use an indexed color palette like GIF. If you want variable transparency, use 32bit PNGs (24 bit color, 8 bit alpha). If you don't care about transparency, use 24 bit PNGs.

PNG-8文件是目前广泛应用的PNG图像格式,其主要有六大块组成:

1.PNG文件标志,为固定的64个字节:0x89504e47 0x0d0a1a0a

文件头数据块IHDR(header chunk)

3.调色板数据块PLTE(palette chunk)

4. sBIT,tRNS块等

5.图像数据块IDAT(image data chunk)

6.图像结束数据IEND(image trailer chunk),固定的96个字节:0x00000000 0x49454e44 0xae426082

这六大块按顺序排列,也就是说IDAT块永远是在PLTE块之后,期间也会有许多其他的区块用来描述信息,例如图像的最后修改时间是多少,图像的创建者是谁等,不过这些区块的信息对我们来说都是可有可无的描述信息,故压缩时一般先向这些区块开刀。

数据库1-4

除了PNG文件标志,其中四大数据块和文件尾都是由统一的数据块文件结构描述的:

Chunk Length:4bt
Chunk Type:4bt
Chunk Data:Chunk Length的长度
Chunk CRC:4 byte

例如IHDR块的数据长度为13,既 

Chunk Length = 13
Chunk Type = "IHDR"

IHDR块:

用来描述图像的基本信息,其格式为:

图像宽:    4bt
图像高:    4bt
图像色深: 4bt
颜色类型: 1bt
压缩方法: 1bt
滤波方法: 1bt
扫描方法: 1bt

PLTE块:

这个就是传说中放置调色盘数据的地方啦,其格式为:

循环
RED:    1bt
GREEN:1bt
BLUE:  1bt
END

循环长度嘛,不就是Chunk Length / 3的长度嘛,而且Chunk Length一定为3的倍数。

tRNS块:

这个块时有时无,主要是看你是否使用了透明色。该区块的格式为:

循环
if(对应调色盘颜色非透明)

0xFF:  1bt
else
 0x00:  1bt
END

循环长度为调色盘的颜色数,相当于调色盘颜色表的一个对应表,标识该颜色是否透明,0xFF不透明,0x00透明。故如果用UltraEdit查看PNG文件的二进制编码,如果看到一大片FF,一般就是tRNS区块啦,因为一个PNG文件一般只有一个透明色。

IDAT块:这个就是存放图像数据的地方啦,这里要注意的是一个PNG文件可能有多个IDAT区块,而其他三大区块只可能有一个。IDAT 区块是经过压缩的,所以数据不可读 ,压缩算法一般为LZ77滑动窗口算法,如果硬要看里面的数据的话,用zlib库也是可以的,CoCoMo当年就见过 Windows Mobile上的帝国时代巨变态的用zlib库压缩和解压该区块来进一步减少PNG文件大小,真是寸K寸金啊

IEND块:该区块虽然也按照数据块的结构,但Chunk Data是没有的,所以是固定的96个字节:0x00000000 0x49454e44 0xae426082

IEND数据块的长度总是0(00 00 00 00,除非人为加入信息),数据标识总是IEND(49 45 4E 44),因此,CRC码也总是AE 42 60 82。

PNG图像压缩: 


        了解了PNG的文件结构,压缩就有的放矢了。压缩有6个级别,可以根据需要选择。
Level1:读取PNG文件,将除六大块之外的所有区块都过滤掉
Level2:文件头是固定的0x89504e47 0x0d0a1a0a,文件尾是固定的0x00000000 0x49454e44 0xae426082,去掉!
Level3:每个区块的Chunk Type我们是否需要呢?很明显,我们自己写的压缩格式自己应该清楚是按照什么样的顺序,去掉!
Level4:每个区块的Chunk Length我们是否需要呢?
           IHDR块:定长13个字节,明显不需要,去掉。
           PLTE块:最多128个颜色,为撒要用4byte来记录区块长度而不是用1byte来记录颜色数呢?
           tRNS块:既然有颜色数,tRNS又是调色盘颜色表的对应表,既数量与颜色数相同,为撒还需要呢?
           IDAT块:我想这个是唯一需要4byte来记录长度的区块。
Level5:每个区块的Chunk CRC是否需要呢?
           因为计算CRC需要一些时间,但对于字节较少的区块一般可以忽略不计,所以对于这个问题还是由程序员自己决定吧。对于CRC的计算可以参看CoCoMo的另一篇Blog“PNG文件的CRC码计算”
Level6:每个区块我们是否要原封不动的保存期数据呢?
          IHDR块:除了宽、高、色深是需要的,后面那4byte的信息是固定的0x03000000
          PLTE块:为撒要用3byte来表示RGB而不是2byte的565格式?压缩方法可以参看CoCoMo的另一篇Blog“关于PNG图像压缩的一点感悟”
          tRNS块:我想tRNS块是冗余最多的区块了吧,大段大段的0xFF明显没有必要,一般的PNG文件只有一个透明色,为撒要用对应表的方法而不是一个索 引来记录到底哪个是透明色呢?由于颜色数最多128,所以只需1byte就可以代替tRNS那么多0xFF啦。
          IDAT块:么想法,如果你够变态,把zlib加进来吧!

PNG图像解压:

创建了自定义的文件,J2ME端读取后,就面临解压的问题了。我们可以利用此函数来创建

Image:
static Image
createImage(byte[] imageData, int imageOffset, int imageLength)

前提是传入的imageData与PNG未被压缩前的一致。因为PNG文件格式是固定的,所以读取自定义的压缩文件后,开始将那些默认的数据再添加进去,实现解压的目的。下面就开始解压之旅吧!
首先要创建一个ByteArrayOutputStream out

1.写入文件头:
out.writeInt(0x89504e47);
out.writeInt(0x0d0a1a0a);

2.写入IHDR块
out.writeInt(13);
out.writeInt(0x49484452);  //0x49484452为Chunk Type "IHDR"
out.writeInt(width);
out.writeInt(height);
out.writeByte(depth);
out.writeInt(0x03000000);  //压缩时舍掉的4byte,默认0x03000000
out.writeInt(crc);
其他区块方法一致,故略过。。。

3.写入文件尾
out.writeInt(0x00000000);
out.writeInt(0x49454e44);
out.writeInt(0xae426082);

4.转换成数组,创建Image
byte[] pngBuffer = out.toByteArray();
Image image = Image.createImage(pngBuffer, 0, pngBuffer.length);

哈哈,大功告成。这里注意如果中途数据写入有错误,经常会出现创建Image失败的异常,而且非常不好调试,不过只要自定的压缩格式定下来后,对应的创建Image的函数只要写一次,以后基本不会出问题哈。

PNG图像加解密

很多人都担心自己辛苦创作的漂亮的美术图片很easy就被别人拿到了,究其原因是由于PNG文件格式是固定的,稍微了解的人用UltraEdit很容易就 能找到IHDR,PLTE等标识了。CoCoMo就经常看GameLoft的图像文件,哈哈。一般是2byte的Length,然后紧接着图片数据,都放 在一个文件里,直接拷贝2进制然后粘贴到一个新文件里就是一幅图。后来的加密技术会把PNG分块,例如前100个字节一块,紧接着1K一块,最后剩余字节 一块,然后把块顺序打乱,用2byte来记录总长度,1byte记录顺序,但是这并没有从根本上消除IHDR,IEND这些显眼的定位标识,好像在对破解 者说:嘿,看,我就在这里!
       现在了解了之前的压缩和解压技术,这个问题也就迎刃而解了,因为Chunk Length,Chunk Type和Chunk CRC这些东西都消失了,甚至连数据块本身的数据都修改了,我可以按照ImageWidth、ImageHeight、ImageDepth的顺序写数 据,也可以倒过来写。我想再牛的PNG分析器也是无能为力的吧,唯一可以定位的就只有IDAT区块了,不过就算得到该区块的数据,也应该是一张黑白图。

-----------------------------------------------------------------

-----------------------------------------------------------------

-----------------------------------------------------------------

附录

PNG文件结构分析(上:了解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文件格式中的数据块

数据块名称多数据块可选否位置限制
文件头数据块第一块
基色和白色点数据块在PLTE和IDAT之前
图像γ数据块在PLTE和IDAT之前
样本有效位数据块在PLTE和IDAT之前
调色板数据块在IDAT之前
背景颜色数据块在PLTE之后IDAT之前
图像直方图数据块在PLTE之后IDAT之前
图像透明数据块在PLTE之后IDAT之前
(专用公共数据块)在IDAT之前
物理像素尺寸数据块在IDAT之前
(专用公共数据块)在IDAT之前
图像数据块与其他IDAT连续
图像最后修改时间数据块无限制
文本信息数据块无限制
压缩文本数据块无限制
(专用公共数据块)无限制
(专用公共数据块)无限制
(专用公共数据块)无限制
(专用公共数据块)无限制
图像结束数据最后一个数据块

为了简单起见,我们假设在我们使用的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字节组成,它的格式如下表所示。

域的名称字节数说明
Width4 bytes图像宽度,以像素为单位
Height4 bytes图像高度,以像素为单位
Bit depth1 byte图像深度: 
索引彩色图像:1,2,4或8 
灰度图像:1,2,4,8或16 
真彩色图像:8或16
ColorType1 byte颜色类型:
0:灰度图像, 1,2,4,8或16 
2:真彩色图像,8或16 
3:索引彩色图像,1,2,4或8 
4:带α通道数据的灰度图像,8或16 
6:带α通道数据的真彩色图像,8或16
Compression method1 byte压缩方法(LZ77派生算法)
Filter method1 byte滤波器方法
Interlace method1 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

PLTE

调色板数据块PLTE(palette chunk)包含有与索引彩色图像(indexed-color image)相关的彩色变换数据,它仅与索引彩色图像有关,而且要放在图像数据块(image data chunk)之前。

PLTE数据块是定义图像的调色板信息,PLTE可以包含1~256个调色板信息,每一个调色板信息由3个字节组成:

颜色字节意义
Red1 byte0 = 黑色, 255 = 红
Green1 byte0 = 黑色, 255 = 绿色
Blue1 byte0 = 黑色, 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, 为了方便大家观看,我们将图像放大:

PNG图片结构分析与加密和加密-转

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

PNG图片结构分析与加密和加密-转

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

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

00000008~00000020:

PNG图片结构分析与加密和加密-转
00 00 00 0D  #说明IHDR头块长为13
49 48 44 52  #IHDR标识
00 00 01 00  #图像的宽 hex-100 = dec-256像素
00 00 01 00  #图像的高 hex-100 = dec-256像素
04 #色深,2^4 = 16,是一个16色的图像(也有可能颜色数不超过16,当然,如果颜色数不超过8,用03表示更合适)
03 #颜色类型,索引图像
00 #PNG Spec规定此处总为0(非0值为将来使用更好的压缩方法预留),表示使压缩方法(LZ77派生算法)
00 #同上
00 #非隔行扫描
AE 5C B5 55 #CRC校验

00000021~0000002F:

PNG图片结构分析与加密和加密-转

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

00000030~00000062:

PNG图片结构分析与加密和加密-转

这里是调色板信息

00 00 00 27 #说明调色板数据长为39字节,既13个颜色数
50 4C 54 45 #PLTE标识
B7 00 34 #颜色0
FF 99 00 #颜色1
60 00 73 #颜色2
FF 0F 00 #颜色3
FF ED 00 #颜色4
09 00 B2 #颜色5
FF 66 00 #颜色6
FF 3B 00 #颜色7
E2 00 15 #颜色8
8B 00 54 #颜色9
FF C1 00 #颜色10
33 00 99 #颜色11
FF FF 00 #颜色12
48 29 75 2C #CRC校验

00000063~000000C5:

PNG图片结构分析与加密和加密-转

这部分包含了pHYs、tExt两种类型的数据块共3块,由于并不太重要,因此也不再详细描述了。

000000C6~000001a04:

PNG图片结构分析与加密和加密-转

以上选中部分是IDAT数据块

00 00 00 D3 #数据长度为211字节
49 44 41 54 #IDAT标识
78 9C ED CE...... AC CA 7A EF  #压缩的数据,LZ77派生压缩方法 211字节
34 47 57 34 #CRC校验

000001a00~000001b00

PNG图片结构分析与加密和加密-转

IEND数据块,这部分正如上所说,通常都应该是 00 00 00 00 49 45 4E 44 AE 42 60 82

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

删除了辅助数据块后的PNG文件,现在文件大小为147字节,原文件大小为261字节,文件大小减少后,并不影响图像的内容。

其实,我们可以通过改变调色板的色值来完成一些又趣的事情,比如说实现云彩/水波的流动效果,实现图像的淡入淡出效果等等,在此,给出一个链接给大家看也许更直接:


想像一下,有一个游戏,里面有很多种颜色的人,图片完全一样,只是人物衣服的颜色不同。比如街霸中真的红色的Ken和假的青色的Ken,它们的图形一模一样,只是颜色换掉了。
这时你会怎么做呢?画好多张图片?拜托,都21世纪了,别做这种没有一点技术含量的工作好不好?聪明的你一定会想,如果可以把里面的红色“替换”成青色就好了。OK,那我们就来替换。
GIF、PNG等很多格式的图片,都是用调色板来记录颜色的。比如记录3号颜色为0xff0000红色,那么我们把3号颜色改为青色的代码,图片中的所有标记为3号颜色的区域都变成青色了。怎么样?说起来好像很简单吧?^_^下面我们用J2ME手机用的最多的png格式的图片来完成这项工作。
首先我们要清楚png图片的格式。
首先是8 byte的png标志。其次是若干个块,每个块有下列结构:
4 byte Length 块的data区的length
4 byte Type 块的类型
length byte Data 块的data
4 byte CRC 块类型和data两个区共length+4字节的CRC校验和
我们感兴趣的块是调色板块,类型区的内容是'P'、'L'、'T'、'E'四个字节,data区是所有颜色按照0xRRGGBB的格式排列,length区的值是颜色数*3。OK,基础知识准备完毕。(CRC校验和的算法和png结构的详细信息可参考http://www.w3.org/TR/PNG-Structure.html
接下来设计我们的超级牛X的PalettedImage类,首先提供两个工厂方法,一个通过文件名从包中创建图片,另一个直接从byte数组中创建。创建后马上执行analyze方法,得到颜色数、调色板偏移、CRC校验码偏移等值(针对一张图片这些值是不变的)。以后就可以用setColor替换某种颜色或者用setPalette替换整个调色板的所有颜色值了。每次替换颜色后都记得要重新生成正确的CRC校验和,并重新创建图片。

这个类的好处在于不必携带极多的图片资源,而只需要一张图片和若干套调色板信息就好了。缺点在于它会占用一个图片的2倍的内存(imgData数组和image对象),不过你可以在得到新Image后就把PalettedImage释放掉。

附带一个简单的示例(点此下载),按5键ken就会换衣服。已经无法下载了


如 上说过,IDAT数据块是使用了LZ77压缩算法生成的,由于受限于手机处理器的能力,因此,如果我们在生成IDAT数据块时仍然使用LZ77压缩算法, 将会使效率大打折扣,因此,为了效率,只能使用无压缩的LZ77算法,关于LZ77算法的具体实现,此文不打算深究,如果你对LZ77算法的JAVA实现 有兴趣,可以参考以下两个站点:

PNG文件结构分析(下:在手机上生成PNG文件)

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

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

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

(调色板对照图)

12111098765
1110987654
109876543
98765432
87654321
76543210
65432100
54321000

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

012111098765
01110987654
0109876543
098765432
087654321
076543210
065432100
054321000

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

0203169135101
018615211884
016913510167
01521188450
01351016733
0118845016
010167330
08450160

最后,我们对这些数据进行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图片了


转载与-http://t.zoukankan.com/amws-p-3336536.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

  • 我的微信
  • 这是我的微信扫一扫
  • weinxin
  • 我的微信公众号
  • 我的微信公众号扫一扫
  • weinxin

发表评论

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen: