李錦俊(mybios)的blog

PNG是20世紀90年代中期開始開發(fā)的圖像文件存儲格式，其目的是企圖替代GIF和TIFF文件格式，同時增加一些GIF文件格式所不具備的特性。流式網(wǎng)絡圖形格式(Portable Network Graphic Format，PNG)名稱來源于非官方的“PNG's Not GIF”，是一種位圖文件(bitmap file)存儲格式，讀成“ping”。PNG用來存儲灰度圖像時，灰度圖像的深度可多到16位，存儲彩色圖像時，彩色圖像的深度可多到48位，并且還可存儲多到16位的α通道數(shù)據(jù)。PNG使用從LZ77派生的無損數(shù)據(jù)壓縮算法。

PNG數(shù)據(jù)塊（Chunk）

PNG定義了兩種類型的數(shù)據(jù)塊，一種是稱為關鍵數(shù)據(jù)塊(critical chunk)，這是標準的數(shù)據(jù)塊，另一種叫做輔助數(shù)據(jù)塊(ancillary chunks)，這是可選的數(shù)據(jù)塊。關鍵數(shù)據(jù)塊定義了4個標準數(shù)據(jù)塊，每個PNG文件都必須包含它們，PNG讀寫軟件也都必須要支持這些數(shù)據(jù)塊。雖然PNG文件規(guī)范沒有要求PNG編譯碼器對可選數(shù)據(jù)塊進行編碼和譯碼，但規(guī)范提倡支持可選數(shù)據(jù)塊。

下表就是PNG中數(shù)據(jù)塊的類別，其中，關鍵數(shù)據(jù)塊部分我們使用深色背景加以區(qū)分。

為了簡單起見，我們假設在我們使用的PNG文件中，這4個數(shù)據(jù)塊按以上先后順序進行存儲，并且都只出現(xiàn)一次。

數(shù)據(jù)塊結構

PNG文件中，每個數(shù)據(jù)塊由4個部分組成，如下：

CRC(cyclic redundancy check)域中的值是對Chunk Type Code域和Chunk Data域中的數(shù)據(jù)進行計算得到的。CRC具體算法定義在ISO 3309和ITU-T V.42中，其值按下面的CRC碼生成多項式進行計算：

x³²+x²⁶+x²³+x²²+x¹⁶+x¹²+x¹¹+x¹⁰+x⁸+x⁷+x⁵+x⁴+x²+x+1

下面，我們依次來了解一下各個關鍵數(shù)據(jù)塊的結構吧。

IHDR

文件頭數(shù)據(jù)塊IHDR(header chunk)：它包含有PNG文件中存儲的圖像數(shù)據(jù)的基本信息，并要作為第一個數(shù)據(jù)塊出現(xiàn)在PNG數(shù)據(jù)流中，而且一個PNG數(shù)據(jù)流中只能有一個文件頭數(shù)據(jù)塊。

文件頭數(shù)據(jù)塊由13字節(jié)組成，它的格式如下表所示。

由于我們研究的是手機上的PNG，因此，首先我們看看MIDP1.0對所使用PNG圖片的要求吧：

• 在MIDP1.0中，我們只可以使用1.0版本的PNG圖片。并且，所以的PNG關鍵數(shù)據(jù)塊都有特別要求：
  IHDR
• 文件大小：MIDP支持任意大小的PNG圖片，然而，實際上，如果一個圖片過大，會由于內存耗盡而無法讀取。
• 顏色類型：所有顏色類型都有被支持，雖然這些顏色的顯示依賴于實際設備的顯示能力。同時，MIDP也能支持alpha通道，但是，所有的alpha通道信息都會被忽略并且當作不透明的顏色對待。
• 色深：所有的色深都能被支持。
• 壓縮方法：僅支持壓縮方式0（deflate壓縮方式），這和jar文件的壓縮方式完全相同，所以，PNG圖片數(shù)據(jù)的解壓和jar文件的解壓可以使用相同的代碼。（其實這也就是為什么J2ME能很好的支持PNG圖像的原因：））
• 濾波器方法：盡管在PNG的白皮書中僅定義了方法0，然而所有的5種方法都被支持！
• 隔行掃描：雖然MIDP支持0、1兩種方式，然而，當使用隔行掃描時，MIDP卻不會真正的使用隔行掃描方式來顯示。
• PLTE chunk：支持
• IDAT chunk：圖像信息必須使用5種過濾方式中的方式0 (None, Sub, Up, Average, Paeth)
• IEND chunk：當IEND數(shù)據(jù)塊被找到時，這個PNG圖像才認為是合法的PNG圖像。
• 可選數(shù)據(jù)塊：MIDP可以支持下列輔助數(shù)據(jù)塊，然而，這卻不是必須的。

  bKGD cHRM gAMA hIST iCCP iTXt pHYs
  sBIT sPLT sRGB tEXt tIME tRNS zTXt

關于更多的信息，可以參考http://www.w3.org/TR/REC-png.html

PLTE

調色板數(shù)據(jù)塊PLTE(palette chunk)包含有與索引彩色圖像(indexed-color image)相關的彩色變換數(shù)據(jù)，它僅與索引彩色圖像有關，而且要放在圖像數(shù)據(jù)塊(image data chunk)之前。

PLTE數(shù)據(jù)塊是定義圖像的調色板信息，PLTE可以包含1~256個調色板信息，每一個調色板信息由3個字節(jié)組成：

因此，調色板的長度應該是3的倍數(shù)，否則，這將是一個非法的調色板。

對于索引圖像，調色板信息是必須的，調色板的顏色索引從0開始編號，然后是1、2……，調色板的顏色數(shù)不能超過色深中規(guī)定的顏色數(shù)（如圖像色深為4的時候，調色板中的顏色數(shù)不可以超過2^4=16），否則，這將導致PNG圖像不合法。

真彩色圖像和帶α通道數(shù)據(jù)的真彩色圖像也可以有調色板數(shù)據(jù)塊，目的是便于非真彩色顯示程序用它來量化圖像數(shù)據(jù)，從而顯示該圖像。

IDAT

圖像數(shù)據(jù)塊IDAT(image data chunk)：它存儲實際的數(shù)據(jù)，在數(shù)據(jù)流中可包含多個連續(xù)順序的圖像數(shù)據(jù)塊。

IDAT存放著圖像真正的數(shù)據(jù)信息，因此，如果能夠了解IDAT的結構，我們就可以很方便的生成PNG圖像。

IEND

圖像結束數(shù)據(jù)IEND(image trailer chunk)：它用來標記PNG文件或者數(shù)據(jù)流已經(jīng)結束，并且必須要放在文件的尾部。

如果我們仔細觀察PNG文件，我們會發(fā)現(xiàn)，文件的結尾12個字符看起來總應該是這樣的：

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

不難明白，由于數(shù)據(jù)塊結構的定義，IEND數(shù)據(jù)塊的長度總是0（00 00 00 00，除非人為加入信息），數(shù)據(jù)標識總是IEND（49 45 4E 44），因此，CRC碼也總是AE 42 60 82。

實例研究PNG

以下是由Fireworks生成的一幅圖像，圖像大小為8*8，為了方便大家觀看，我們將圖像放大：

使用UltraEdit32打開該文件，如下：
00000000~00000007：

可以看到，選中的頭8個字節(jié)即為PNG文件的標識。

接下來的地方就是IHDR數(shù)據(jù)塊了：

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色的圖像（也有可能顏色數(shù)不超過16，當然，如果顏色數(shù)不超過8，用03表示更合適）
• 03 顏色類型，索引圖像
• 00 PNG Spec規(guī)定此處總為0（非0值為將來使用更好的壓縮方法預留），表示使壓縮方法(LZ77派生算法)
• 00 同上
• 00 非隔行掃描
• 36 21 A3 B8 CRC校驗

00000021~0000002F：

可選數(shù)據(jù)塊sBIT，顏色采樣率，RGB都是256（2^8=256）

00000030~00000062：

這里是調色板信息

• 00 00 00 27 說明調色板數(shù)據(jù)長為39字節(jié)，既13個顏色數(shù)
• 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兩種類型的數(shù)據(jù)塊共3塊，由于并不太重要，因此也不再詳細描述了。

000000C0~000000F8：

以上選中部分是IDAT數(shù)據(jù)塊

• 00 00 00 27 數(shù)據(jù)長為39字節(jié)
• 49 44 41 54 IDAT標識
• 78 9C…… 壓縮的數(shù)據(jù)，LZ77派生壓縮方法
• DA 12 06 A5 CRC校驗

IDAT中壓縮數(shù)據(jù)部分在后面會有詳細的介紹。

000000F9~00000104：

IEND數(shù)據(jù)塊，這部分正如上所說，通常都應該是

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

至此，我們已經(jīng)能夠從一個PNG文件中識別出各個數(shù)據(jù)塊了。由于PNG中規(guī)定除關鍵數(shù)據(jù)塊外，其它的輔助數(shù)據(jù)塊都為可選部分，因此，有了這個標準后，我們可以通過刪除所有的輔助數(shù)據(jù)塊來減少PNG文件的大小。（當然，需要注意的是，PNG格式可以保存圖像中的層、文字等信息，一旦刪除了這些輔助數(shù)據(jù)塊后，圖像將失去原來的可編輯性。）

刪除了輔助數(shù)據(jù)塊后的PNG文件，現(xiàn)在文件大小為147字節(jié)，原文件大小為261字節(jié)，文件大小減少后，并不影響圖像的內容。

如上說過，IDAT數(shù)據(jù)塊是使用了LZ77壓縮算法生成的，由于受限于手機處理器的能力，因此，如果我們在生成IDAT數(shù)據(jù)塊時仍然使用LZ77壓縮算法，將會使效率大打折扣，因此，為了效率，只能使用無壓縮的LZ77算法，關于LZ77算法的具體實現(xiàn)，此文不打算深究，如果你對LZ77算法的JAVA實現(xiàn)有興趣，可以參考以下兩個站點：

• http://jazzlib.sourceforge.net/
• http://www.jcraft.com/jzlib/index.html

參考資料：

PNG文件格式白皮書：http://www.w3.org/TR/REC-png.html
為數(shù)不多的中文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實現(xiàn)：http://jazzlib.sourceforge.net/
LZ77算法的JAVA實現(xiàn)，包括J2ME版本：http://www.jcraft.com/jzlib/index.html