文章介紹了基于32位ARM7芯片LPC2292實現的軟件JPEG解碼算法及應用了此算法的手持JPEG圖像顯示器的設計。

        文章從JPEG的編碼原理入手，針對LPC2292的資源和性能特點，進行了可行性分析。重點論述了Huffman解碼和IDCT解碼的優化算法的實現，很大程度上提高了解碼算法的效率，使得算法在ARM7芯片上的移植成為可能。


1 概述

        在數字圖像處理過程中，JPEG編碼是一種經常運用的壓縮算法，目的是有效地壓縮數字圖像大小，便于存儲和傳輸。其具有壓縮比例高、失真小等特點。目前對應的JPEG解碼方式有兩種：硬件解碼和軟件解碼。硬件解碼是利用硬件解碼芯片來完成對JPEG數據的解碼；軟件解碼則是通過編寫程序來完成對數據的還原。由于軟件解碼需要大量的浮點運算，目前較多的由PC及DSP來實現。 

       本文主要介紹了一種基于Philips公司的ARM芯片LPC2292來實現JPEG圖像軟件解碼的方法及基于此算法實現的手持式JPEG圖像顯示器。

2 JPEG解碼可行性分析

2.1 LPC2292的特點

        LPC2292是一款基于32位ARM7TDMI-S，并支持實時仿真和跟蹤的CPU，帶有256 k字節(kB)嵌入的高速Flash存儲器。128位寬度的存儲器接口和獨特的加速結構使32位代碼能夠在最大時鐘速率下運行。對代碼規模有嚴格控制的應用可使用16位Thumb模式將代碼 規模降低超過30%，而性能的損失卻很小。

2.2 存儲器容量計算

        JPEG解碼涉及到大量的數據計算，因此需要大量的數據緩存器。手持JPEG顯示器的緩存主要包括原始JPEG圖像數據緩存、JPEG解碼緩存以及RGB數據顯示緩存等。原始JPEG圖像數據緩存用于存放需要解碼的JPEG圖像數據，根據JPEG圖像的復雜度及壓縮比不同，一般一幀320×240的彩色JPEG圖像的大小在2k～20k字節。JPEG解碼緩存主要用于存放一些JPEG解碼過程中的中間數據，主要包括MCU解碼中Huffman解碼的臨時結果，IDCT解碼的臨時結果等。RGB數據顯示緩存用來存放JPEG解碼完后的RGB原始數據，用于LCD液晶顯示，一幀320×240的彩色16位RGB圖像，共需要320×240×16÷8＝57600字節。

        LPC2292內部帶有16k的SRAM。如果采用整張圖像緩存、解碼完再顯示的話，根據上面的分析，僅顯示緩存區一項就不能滿足需要。因此，設計采用一邊讀取數據、一邊解碼、一邊顯示的策略，來減少對存儲器的需求。

3 具體實現

3.1硬件實現

        JPEG圖像顯示器的硬件實現框圖如下圖所示：
 

圖1  JPEG圖像顯示器硬件框圖

        系統以LPC2292為控制核心，采用CAN總線來從外界讀取原始JPEG數據，彩色LCD顯示模塊則選用TFT6758彩色LCD液晶顯示模塊。LPC2292內部自帶的CAN接口及32位寬度的數據總線，可以很方便的與CAN總線及LCD液晶顯示模塊實現連接。

3.2軟件實現：

       JPEG編碼技術主要包括顏色轉換、DCT變換、量化、熵編碼及Huffman編碼等部分，其數據格式在文獻[1]中進行了詳盡的闡述。

       JPEG解碼主要包括Huffman解碼、反量化及IDCT變換、色彩變換等模塊，其流程框圖如下：

圖2  JPEG圖像解碼軟件流程框圖

3.2.1 Hffman解碼的實現：

       Huffman解碼主要通過反向查找Huffman表來實現。由于查找過程需要大量的移位及循環，效率很低。為了提高效率，軟件事先構造了一張預查找表，該表的維數由宏定義HUFF_LOOKAHEAD來決定。位數低于HUFF_LOOKAHEAD的Huffman編碼，解碼結果都可以從該預查找表中直接讀出，而對于位數大于HUFF_LOOKAHEAD的則再通過移位循環來遍歷Huffman表實現解碼。可以看出，預查找表維數越高，則整個Huffman解碼所需的循環移位次數越少，解碼效率越高，但同時，需要存放預查找表的空間也越高，其占用字節數為2的HUFF_LOOKAHEAD次方字節。

       預查表分兩部分，其構造思想如下：

       假設某個亮度的DC 系數的Huffman編碼表如下，HUFF_LOOKAHEAD的值為4：

表1  亮度DC Huffman編碼表

則構造2張維數為24的表，一張中的數據為碼長，另一張為真實值。

       表中第一行碼字00代表的是真實數據0，則構造的碼長表中，序號為00XX2（其中X表示0或1，即00XX2為0－310）的數據全為2，真實值表中，序號為00XX2（0－310）的數據全為0；

       表中第二行碼字010代表的是真實數據1，同理碼長表中，序號為010X2（4－510）的數據全為3，真實值表中，序號為010X2（4－510）的數據全為1；

       依次類推，直到填滿，序號為11112（1510）的碼字在Huffman表中沒有出現，則在2張預查表中，最后一個數據均為0，構造的預查表如下：

碼長表

{2, 2, 2, 2, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 4, 0 }

真實值表

{0, 0, 0, 0, 1, 1, 2, 2, 3, 3, 4, 4, 5, 5, 6, 0}

       預查找解碼時，收到一串2進制數據，我們先將前4個bit（HUFF_LOOKAHEAD = 4）的數據讀入移位緩存，假設為01012（510），則我們在2張預查表中分別讀取序號為5的數據（第6個數據），得到碼長為3，真實值為1，因此解碼得到第一個真實數據為1，丟棄緩存中前3個bit，從接收到的數據流中重新移入3個bit的數據，與之前的最后一位1組成一個新的4bit數據，進行下一次預查找解碼。

       3.2.2 反量化及IDCT變換的實現

       在進行IDCT變換前，先要將數據進行反量化及重排列處理。將8×8塊中的數據對應的乘上量化表中的系數，再將64個數據進行Z字型的重新排列，用于后面的IDCT變換。

       IDCT可以用下面的計算公式來實現：

       其中x，y＝0...7   當u＝v＝0時，C(u)=C(v)=0.5，其他情況 C(u)=C(v)=1

       由于ARM7芯片在數據處理方面性能遠不及DSP，如果簡單按照這個公式來計算IDCT變換，則會因為運算量太大而嚴重影響解碼速度。因此，文獻[2]中提到了IDCT變換的另一種實現算法。該算法的思想是將二維8×8數組的IDCT轉換為行和列的2個一維數組的IDCT，進而再轉換成一系列簡單的加減法及與常數相乘的乘法運算，大大減小了運算量。

       3.2.3 色彩轉換的實現：

       經過IDCT變換后，JPEG數據被解碼成YCrCb信號。圖像數據要在液晶顯示器上顯示，還需要進行最后一步變換，即將YCrCb信號轉換成RGB信號，兩者對應的轉換公式如下：

R = Y + 1.402 ×(Cr-128)

G = Y - 0.34414×(Cb-128) - 0.71414×(Cr-128)

B = Y + 1.772 ×(Cb-128)

       其中，R、G、B、Y、Cr、Cb都是0~255的無符號數據。

       公式中有浮點數的乘法運算，為了提高性能，軟件事先將1.402×（0~255）、0.34414×（0~255）、0.71414×（0~255）以及1.772×（0~255）的結果制成表格，計算時只要查表即可得到結果，免去了由于浮點運算而占用的大量處理時間。

       4  結論

       由于采用了Huffman預解碼查找表，用簡單的查表語句代替了Huffman解碼過程中大量繁瑣的循環和移位操作；優化的IDCT算法及色彩轉換算法，減少了大量復雜的乘法運算；提高了解碼的效率，大大壓縮了解碼所需的時間，使得原本復雜的解碼算法在數據處理能力并不出色的ARM7芯片上得以很好的實現。

       設計完成的手持JPEG圖像顯示器如圖3所示，其已經在自行設計的電纜排管疏通監視機器人項目中取得了很好的效果，在320×240的液晶屏上顯示的JPEG解碼圖像效果如圖4所示：

圖3  手持JPEG圖像顯示器

圖4  JPEG顯示器圖像顯示效果

        本文作者創新點：將計算量龐大的JPEG解碼算法成功地在數據處理性能并不出眾的ARM7系統上實現了移植，并由此設計完成了手持式彩色圖像顯示器。

       參考文獻:

       [1]邢賽鵬,平西建,詹杰勇.JPEG圖像數據格式簡明分析[J].微計算機信息,2005,12-3:166-168

       [2]魏忠義，朱磊，基于DSP的JPEG圖像解碼算法的實現 [J]，陜西 西安，2005年

       [3]Information Technology Digital Compression And Coding Of Continuous-Tone Still Images Requirements And Guidelines   CCITT Recommendation T.81