PNG文件結構分析

PNG文件結構分析(上：瞭解PNG文件存儲格式)

前言

我們都知道，在進行J2ME的手機應用程序開發的時候，在圖片的使用上，我們可以使用PNG格式的圖片（甚至於在有的手機上，我們只可以使用PNG格式的圖片），儘管使用圖片可以爲我們的應用程序增加不少亮點，然而，只支持PNG格式的圖片卻又限制了我們進一步發揮的可能性（其實，應該說是由於手機平臺上的處理能力有限）。在MIDP2中，或者某些廠商（如NOKIA）提供的API中，提供了drawPixels/getPixels的方法，這些方法進一步提高了開發者處理圖片的靈活性，然而，在MIDP2還未完全普及的今天，我們需要在MIDP1 .0中實現這類方法還屬於異想天開，因此，爲了實現更高級的應用，我們必須充分挖掘PNG的潛力。

PNG的文件結構

對於一個PNG文件來說，其文件頭總是由位固定的字節來描述的：

其中第一個字節0x89超出了ASCII字符的範圍，這是爲了避免某些軟件將PNG文件當做文本文件來處理。文件中剩餘的部分由3個以上的PNG的數據塊（Chunk）按照特定的順序組成，因此，一個標準的PNG文件結構應該如下：

PNG數據塊（Chunk）

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

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

爲了簡單起見，我們假設在我們使用的PNG文件中，這4個數據塊按以上先後順序進行存儲，並且都只出現一次。

數據塊結構

PNG文件中，每個數據塊由4個部分組成，如下：

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

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

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

IHDR

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

文件頭數據塊由13字節組成，它的格式如下表所示。

由於我們研究的是手機上的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個字節組成：

因此，調色板的長度應該是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

PNG文件結構分析(下：在手機上生成PNG文件)

上面我們已經對PNG的存儲格式有了瞭解，因此，生成PNG圖片只需要按照以上的數據塊寫入文件即可。

(由於IHDR、PLTE的結構都非常簡單，因此，這裏我們只是重點講一講IDAT的生成方法，IHDR和PLTE的數據內容都沿用以上的數據內容)

問題確實是這樣的，我們知道，對於大多數的圖形文件來說，我們都可以將實際的圖像內容映射爲一個二維的顏色數組，對於上面的PNG文件，由於它用的是16色的調色板（實際是13色），因此，對於圖片的映射可以如下：

(調色板對照圖)

PNG Spec中指出，如果PNG文件不是採用隔行掃描方法存儲的話，那麼，數據是按照行(ScanLine)來存儲的，爲了區分第一行，PNG規定在每一行的前面加上0以示區分，因此，上面的圖像映射應該如下：

另外，需要注意的是，由於PNG在存儲圖像時爲了節省空間，因此每一行是按照位(Bit)來存儲的，而並不是我們想象的字節（Byte），如果你沒有忘記的話，我們的IHDR數據塊中的色深就指明瞭這一點，所以，爲了湊成PNG所需要的IDAT，我們的數據得改成如下：

最後，我們對這些數據進行LZ77壓縮就可以得到IDAT的正確內容了。

然而，事情並不是這麼簡單，因爲我們研究的是手機上的PNG，如果需要在手機上完成LZ77壓縮工作，消耗的時間是可想而知的，因此，我們得再想辦法加減少壓縮時消耗的時間。

好在LZ77也提供了無壓縮的壓縮方法（奇怪吧？），因此，我們只需要簡單的使用無壓縮的方式寫入數據就可以了，這樣雖然浪費了空間，卻換回了時間！

好了，讓我們看一看怎麼樣湊成無壓縮的LZ77壓縮塊：

其中的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圖片了。

生成的PNG文件：

範例(附源程序)

• 有效的減少PNG格式文件的大小
• 通過改變調色板實現類似雲彩流動的效果(源程序包含在此jar文件中)