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
2.文件頭數據塊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: 4byte
Chunk Type: 4byte
Chunk Data: Chunk Length的長度
Chunk CRC: 4byte
例如IHDR塊的數據長度為13，既
Chunk Length = 13
Chunk Type = "IHDR"
IHDR塊：
用來描述圖像的基本信息，其格式為：
圖像寬： 4byte
圖像高： 4byte
圖像色深： 4byte
顏色類型： 1byte
壓縮方法： 1byte
濾波方法： 1byte
掃描方法： 1byte
曾經有人問過我，撒叫濾波方法和掃描方法，汗，說實話我也不知道，不過我們是在做手機游戲，不是在搞圖形學不是嘛。
PLTE塊：
這個就是傳說中放置調色盤數據的地方啦，其格式為：
循環
RED： 1byte
GREEN：1byte
BLUE： 1byte
END
循環長度嘛，不就是Chunk Length / 3的長度嘛，而且Chunk Length一定為3的倍數。
tRNS塊：
這個塊時有時無，主要是看你是否使用了透明色。該區塊的格式為：
循環
if(對應調色盤顏色非透明)
0xFF： 1byte
else
0x00： 1byte
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文件格式中的數據塊 | ||||
| 數據塊符號 | 數據塊名稱 | 多數據塊 | 可選否 | 位置限制 |
| 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的結構都非常簡單，因此，這里我們只是重點講一講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圖片了
轉自：http://blog.csdn.net/yshen_dublin/article/details/4416209