基于LPC2292的手持JPEG圖像顯示器設(shè)計(jì)

摘要：文章介紹了基于32位ARM7芯片LPC2292實(shí)現(xiàn)的軟件JPEG解碼算法及應(yīng)用了此算法的手持JPEG圖像顯示器的設(shè)計(jì)。文章從JPEG的編碼原理入手，針對(duì)LPC2292的資源和性能特點(diǎn)，進(jìn)行了可行性分析。重點(diǎn)論述了Huffman解碼和IDCT解碼的優(yōu)化算法的實(shí)現(xiàn)，很大程度上提高了解碼算法的效率，使得算法在ARM7芯片上的移植成為可能。
關(guān)鍵字:JPEG解碼;Huffman解碼;IDCT解碼

1 概述

在數(shù)字圖像處理過(guò)程中，JPEG編碼是一種經(jīng)常運(yùn)用的壓縮算法，目的是有效地壓縮數(shù)字圖像大小，便于存儲(chǔ)和傳輸。其具有壓縮比例高、失真小等特點(diǎn)。目前對(duì)應(yīng)的JPEG解碼方式有兩種：硬件解碼和軟件解碼。硬件解碼是利用硬件解碼芯片來(lái)完成對(duì)JPEG數(shù)據(jù)的解碼；軟件解碼則是通過(guò)編寫程序來(lái)完成對(duì)數(shù)據(jù)的還原。由于軟件解碼需要大量的浮點(diǎn)運(yùn)算，目前較多的由PC及DSP來(lái)實(shí)現(xiàn)。

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

2 JPEG解碼可行性分析

2.1 LPC2292的特點(diǎn)

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

2.2 存儲(chǔ)器容量計(jì)算

JPEG解碼涉及到大量的數(shù)據(jù)計(jì)算，因此需要大量的數(shù)據(jù)緩存器。手持JPEG顯示器的緩存主要包括原始JPEG圖像數(shù)據(jù)緩存、JPEG解碼緩存以及RGB數(shù)據(jù)顯示緩存等。原始JPEG圖像數(shù)據(jù)緩存用于存放需要解碼的JPEG圖像數(shù)據(jù)，根據(jù)JPEG圖像的復(fù)雜度及壓縮比不同，一般一幀320240的彩色JPEG圖像的大小在2k～20k字節(jié)。JPEG解碼緩存主要用于存放一些JPEG解碼過(guò)程中的中間數(shù)據(jù)，主要包括MCU解碼中Huffman解碼的臨時(shí)結(jié)果，IDCT解碼的臨時(shí)結(jié)果等。RGB數(shù)據(jù)顯示緩存用來(lái)存放JPEG解碼完后的RGB原始數(shù)據(jù)，用于LCD液晶顯示，一幀320240的彩色16位RGB圖像，共需要320240168＝57600字節(jié)。

LPC2292內(nèi)部帶有16k的SRAM。如果采用整張圖像緩存、解碼完再顯示的話，根據(jù)上面的分析，僅顯示緩存區(qū)一項(xiàng)就不能滿足需要。因此，設(shè)計(jì)采用一邊讀取數(shù)據(jù)、一邊解碼、一邊顯示的策略，來(lái)減少對(duì)存儲(chǔ)器的需求。

3 具體實(shí)現(xiàn)

3.1硬件實(shí)現(xiàn)

JPEG圖像顯示器的硬件實(shí)現(xiàn)框圖如下圖所示：

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

系統(tǒng)以LPC2292為控制核心，采用CAN總線來(lái)從外界讀取原始JPEG數(shù)據(jù)，彩色LCD顯示模塊則選用TFT6758彩色LCD液晶顯示模塊。LPC2292內(nèi)部自帶的CAN接口及32位寬度的數(shù)據(jù)總線，可以很方便的與CAN總線及LCD液晶顯示模塊實(shí)現(xiàn)連接。

3.2軟件實(shí)現(xiàn)：

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

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

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

3.2.1 Hffman解碼的實(shí)現(xiàn)：

Huffman解碼主要通過(guò)反向查找Huffman表來(lái)實(shí)現(xiàn)。由于查找過(guò)程需要大量的移位及循環(huán)，效率很低。為了提高效率，軟件事先構(gòu)造了一張預(yù)查找表，該表的維數(shù)由宏定義HUFF_LOOKAHEAD來(lái)決定。位數(shù)低于HUFF_LOOKAHEAD的Huffman編碼，解碼結(jié)果都可以從該預(yù)查找表中直接讀出，而對(duì)于位數(shù)大于HUFF_LOOKAHEAD的則再通過(guò)移位循環(huán)來(lái)遍歷Huffman表實(shí)現(xiàn)解碼?？梢钥闯?，預(yù)查找表維數(shù)越高，則整個(gè)Huffman解碼所需的循環(huán)移位次數(shù)越少，解碼效率越高，但同時(shí)，需要存放預(yù)查找表的空間也越高，其占用字節(jié)數(shù)為2的HUFF_LOOKAHEAD次方字節(jié)。

預(yù)查表分兩部分，其構(gòu)造思想如下：

假設(shè)某個(gè)亮度的DC 系數(shù)的Huffman編碼表如下，HUFF_LOOKAHEAD的值為4：

表1 亮度DC Huffman編碼表

則構(gòu)造2張維數(shù)為24的表，一張中的數(shù)據(jù)為碼長(zhǎng)，另一張為真實(shí)值。

表中第一行碼字00代表的是真實(shí)數(shù)據(jù)0，則構(gòu)造的碼長(zhǎng)表中，序號(hào)為00XX2（其中X表示0或1，即00XX2為0－310）的數(shù)據(jù)全為2，真實(shí)值表中，序號(hào)為00XX2（0－310）的數(shù)據(jù)全為0；

表中第二行碼字010代表的是真實(shí)數(shù)據(jù)1，同理碼長(zhǎng)表中，序號(hào)為010X2（4－510）的數(shù)據(jù)全為3，真實(shí)值表中，序號(hào)為010X2（4－510）的數(shù)據(jù)全為1；

依次類推，直到填滿，序號(hào)為11112（1510）的碼字在Huffman表中沒(méi)有出現(xiàn)，則在2張預(yù)查表中，最后一個(gè)數(shù)據(jù)均為0，構(gòu)造的預(yù)查表如下：

碼長(zhǎng)表

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

真實(shí)值表

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

預(yù)查找解碼時(shí)，收到一串2進(jìn)制數(shù)據(jù)，我們先將前4個(gè)bit（HUFF_LOOKAHEAD = 4）的數(shù)據(jù)讀入移位緩存，假設(shè)為01012（510），則我們?cè)?張預(yù)查表中分別讀取序號(hào)為5的數(shù)據(jù)（第6個(gè)數(shù)據(jù)），得到碼長(zhǎng)為3，真實(shí)值為1，因此解碼得到第一個(gè)真實(shí)數(shù)據(jù)為1，丟棄緩存中前3個(gè)bit，從接收到的數(shù)據(jù)流中重新移入3個(gè)bit的數(shù)據(jù)，與之前的最后一位1組成一個(gè)新的4bit數(shù)據(jù)，進(jìn)行下一次預(yù)查找解碼。

3.2.2 反量化及IDCT變換的實(shí)現(xiàn)

在進(jìn)行IDCT變換前，先要將數(shù)據(jù)進(jìn)行反量化及重排列處理。將88塊中的數(shù)據(jù)對(duì)應(yīng)的乘上量化表中的系數(shù)，再將64個(gè)數(shù)據(jù)進(jìn)行Z字型的重新排列，用于后面的IDCT變換。

IDCT可以用下面的計(jì)算公式來(lái)實(shí)現(xiàn)：

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

由于ARM7芯片在數(shù)據(jù)處理方面性能遠(yuǎn)不及DSP，如果簡(jiǎn)單按照這個(gè)公式來(lái)計(jì)算IDCT變換，則會(huì)因?yàn)檫\(yùn)算量太大而嚴(yán)重影響解碼速度。因此，文獻(xiàn)[2]中提到了IDCT變換的另一種實(shí)現(xiàn)算法。該算法的思想是將二維88數(shù)組的IDCT轉(zhuǎn)換為行和列的2個(gè)一維數(shù)組的IDCT，進(jìn)而再轉(zhuǎn)換成一系列簡(jiǎn)單的加減法及與常數(shù)相乘的乘法運(yùn)算，大大減小了運(yùn)算量。

3.2.3 色彩轉(zhuǎn)換的實(shí)現(xiàn)：

經(jīng)過(guò)IDCT變換后，JPEG數(shù)據(jù)被解碼成YCrCb信號(hào)。圖像數(shù)據(jù)要在液晶顯示器上顯示，還需要進(jìn)行最后一步變換，即將YCrCb信號(hào)轉(zhuǎn)換成RGB信號(hào)，兩者對(duì)應(yīng)的轉(zhuǎn)換公式如下：

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的無(wú)符號(hào)數(shù)據(jù)。

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

4 結(jié)論

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

設(shè)計(jì)完成的手持JPEG圖像顯示器如圖3所示，其已經(jīng)在自行設(shè)計(jì)的電纜排管疏通監(jiān)視機(jī)器人項(xiàng)目中取得了很好的效果，在320240的液晶屏上顯示的JPEG解碼圖像效果如圖4所示：

圖3 手持JPEG圖像顯示器

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

本文作者創(chuàng)新點(diǎn)：將計(jì)算量龐大的JPEG解碼算法成功地在數(shù)據(jù)處理性能并不出眾的ARM7

系統(tǒng)上實(shí)現(xiàn)了移植，并由此設(shè)計(jì)完成了手持式彩色圖像顯示器。

參考文獻(xiàn):

[1]邢賽鵬,平西建,詹杰勇.JPEG圖像數(shù)據(jù)格式簡(jiǎn)明分析[J].微計(jì)算機(jī)信息,2005,12-3:166-168

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

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