引言

據(jù)媒體報(bào)道，我國(guó)由于后視鏡盲區(qū)造成的交通事故約占30%。而且，隨著“考駕照”熱不降溫的現(xiàn)象出現(xiàn)，未來(lái)的汽車后視鏡盲區(qū)問(wèn)題更是不容小覷。數(shù)字社會(huì)的形成為數(shù)字化實(shí)時(shí)監(jiān)控提供了契機(jī)，汽車后視場(chǎng)景的數(shù)字化實(shí)時(shí)監(jiān)控成為解決后視鏡盲區(qū)問(wèn)題的研究熱點(diǎn)。

目前，市場(chǎng)上已經(jīng)出現(xiàn)了一些數(shù)字化的汽車監(jiān)控系統(tǒng)，常見(jiàn)的有分屏顯示的監(jiān)控系統(tǒng)、有縫拼接的監(jiān)控系統(tǒng)和第8代“衛(wèi)星”全景行車安全系統(tǒng)。分屏顯示的監(jiān)控系統(tǒng)只是對(duì)圖像進(jìn)行簡(jiǎn)單的分屏顯示，不能實(shí)時(shí)地將車輛周圍的景象顯示在屏幕上;有縫拼接的監(jiān)控系統(tǒng)不是將圖像簡(jiǎn)單地疊加，而是對(duì)圖像拼接處理，形成中間是車子，周圍是圖像的全景圖，缺點(diǎn)在于四個(gè)圖像拼接之處存在明顯的拼接縫;第8代“衛(wèi)星”全景行車安全系統(tǒng)采用超廣角攝像頭，它能夠更好地消除圖像拼接之處的拼接縫，形成汽車全景俯視圖。

Android系統(tǒng)具有平臺(tái)開(kāi)放性，而且谷歌的“開(kāi)放汽車聯(lián)盟(OAA)”致力于實(shí)現(xiàn)汽車與Android設(shè)備的無(wú)縫連接以及直接在汽車上內(nèi)置Android車載系統(tǒng);DM3730

集成了1GHz的ARM Cortex-A8核和800MHz的TMS320C64x+ DSP核，DSP在數(shù)字信號(hào)處理上具有無(wú)可比擬的優(yōu)勢(shì)，更適合進(jìn)行圖像處理。因此，基于Android和DM3730設(shè)計(jì)的車載分布式視頻監(jiān)控系統(tǒng)有著廣闊的應(yīng)用前景。

車載分布式視頻監(jiān)控系統(tǒng)集成了Android平臺(tái)的開(kāi)放性、ARM+DSP的高性能、以太網(wǎng)的可擴(kuò)展性和USB攝像頭的即插即用性，對(duì)實(shí)現(xiàn)汽車數(shù)字化實(shí)時(shí)監(jiān)控有研究意義和應(yīng)用價(jià)值。

1系統(tǒng)的整體設(shè)計(jì)

車載分布式視頻監(jiān)控系統(tǒng)由視頻采集模塊、視頻傳輸模塊、視頻拼接模塊和視頻顯示模塊四個(gè)模塊組成。圖1展示了系統(tǒng)的整體設(shè)計(jì)，圖2展示了系統(tǒng)各模塊之間的硬件接口。

圖1 車載分布式視頻監(jiān)控系統(tǒng)整體設(shè)計(jì)示意圖

圖2 車載分布式視頻監(jiān)控系統(tǒng)硬件接口框圖

①　視頻采集模塊：AM3715開(kāi)發(fā)板通過(guò)USB-HOST接口外接USB攝像頭，通過(guò)Android操作系統(tǒng)的Java本地調(diào)用接口[3](JNI)和V4L2 (video 4 linux 2)視頻驅(qū)動(dòng)框架實(shí)時(shí)采集視頻并顯示。

②　視頻傳輸模塊：兩個(gè)(或多個(gè))AM3715和DM3730開(kāi)發(fā)板之間通過(guò)以太網(wǎng)相連，利用RTP組播協(xié)議和自定義同步機(jī)制將USB攝像頭采集的圖像實(shí)時(shí)傳輸至DM3730開(kāi)發(fā)板的ARM端。

③　視頻拼接模塊：DM3730開(kāi)發(fā)板的ARM端運(yùn)行嵌入式Linux操作系統(tǒng)(或Android操作系統(tǒng))，通過(guò)TI Codec Engine模塊同時(shí)在ARM端和DSP端映射共享內(nèi)存，使得同步接收的兩幅(或多幅)圖像能夠被ARM和DSP同時(shí)訪問(wèn)。針對(duì)車載應(yīng)用擴(kuò)充嵌入式計(jì)算視覺(jué)庫(kù)(EMCV)，并移植和優(yōu)化SURF開(kāi)源項(xiàng)目OpenSURF，DSP端能夠?qū)崟r(shí)拼接兩幅(或多幅)圖像，最后將拼接結(jié)果由共享內(nèi)存返回ARM端。

④　視頻顯示模塊：視頻顯示是通過(guò)跨平臺(tái)多媒體庫(kù)SDL(Simple DirectMedia Layer)來(lái)完成的。其中，AM3715開(kāi)發(fā)板顯示分離的USB攝像頭圖像，DM3730開(kāi)發(fā)板顯示拼接完成的圖像。

2 視頻采集傳輸和顯示

2.1 Android V4L2視頻采集模塊

V4L2從Linux 2.5.x版本的內(nèi)核開(kāi)始出現(xiàn)，為使能UVC驅(qū)動(dòng)和V4L2編程框架，首先需檢查Android內(nèi)核配置選項(xiàng)，以生成視頻設(shè)備文件/dev/videoX(X表示次設(shè)備號(hào))。

利用V4L2進(jìn)行USB攝像頭視頻采集的流程[7]包括：(1)打開(kāi)視頻設(shè)備文件;(2)檢查設(shè)備屬性;(3)設(shè)置視頻格式;(4)幀緩沖區(qū)管理;(5)循環(huán)采集視頻;(6)關(guān)閉視頻設(shè)備。

V4L2介于應(yīng)用程序和硬件設(shè)備之間，應(yīng)用程序可以通過(guò)三種方式訪問(wèn)內(nèi)核層的數(shù)據(jù)：直接讀/寫方式、內(nèi)存映射方式和用戶指針?lè)绞健Ｖ苯幼x/寫方式需要在用戶空間和內(nèi)核空間不斷拷貝數(shù)據(jù)，效率低下;內(nèi)存映射方式把內(nèi)核地址映射到用戶地址空間，進(jìn)程可以直接讀寫內(nèi)存，避免了數(shù)據(jù)的拷貝，具有較高的效率;用戶指針?lè)绞降膬?nèi)存片段是由應(yīng)用程序自己分配的。

車載分布式視頻監(jiān)控系統(tǒng)采用效率較高的內(nèi)存映射方式，系統(tǒng)調(diào)用mmap()能夠?qū)?nèi)核地址映射到用戶地址空間。

2.2 RTP視頻傳輸模塊

鑒于以太網(wǎng)具有高速的傳輸能力和良好的可擴(kuò)展性能，車載分布式視頻監(jiān)控系統(tǒng)通過(guò)RTP組播的方式在Android系統(tǒng)與嵌入式Linux系統(tǒng)之間傳輸U(kuò)SB攝像頭采集的圖像。文獻(xiàn)[8]描述了利用RTP庫(kù)JRTPLIB實(shí)現(xiàn)視頻實(shí)時(shí)傳輸?shù)倪^(guò)程。為了確保兩個(gè)AM3715開(kāi)發(fā)板與DM3730開(kāi)發(fā)板之間圖像傳輸?shù)耐叫?，車載分布式視頻監(jiān)控系統(tǒng)設(shè)計(jì)了同步傳輸協(xié)議，協(xié)議描述如下：

(1)發(fā)送端

①　每個(gè)發(fā)送端等待來(lái)自接收端的視頻幀請(qǐng)求命令’R’，否則不執(zhí)行發(fā)送操作。

②　收到幀請(qǐng)求命令后，發(fā)送端首先向組播地址發(fā)送視頻幀傳輸開(kāi)始標(biāo)識(shí)0xFE，以標(biāo)識(shí)一幀視頻傳輸?shù)拈_(kāi)始。

③　將YUY2格式的圖像依次向組播地址傳輸，每次傳輸m行，傳輸n次，并在每個(gè)RTP數(shù)據(jù)包的首字節(jié)位置添加RTP包傳輸序號(hào)(序號(hào)從0開(kāi)始，依次增1)。假設(shè)YUY2圖像寬度為width，高度為height，由于平均一個(gè)像素占2B，所以每次傳輸?shù)腞TP包數(shù)據(jù)大小為(2m*width+1)B，傳輸次數(shù)n = height/m。

④　傳輸結(jié)束時(shí)，向組播地址發(fā)送視頻幀傳輸結(jié)束標(biāo)識(shí)0xFF，以標(biāo)志一幀視頻傳輸?shù)慕Y(jié)束。

(2)接收端

①　接收端向組播地址發(fā)送幀請(qǐng)求命令’R’，然后啟動(dòng)軟件電子狗，并處于阻塞等待狀態(tài)。

②　若軟件電子狗計(jì)時(shí)結(jié)束時(shí)仍未被喂狗，說(shuō)明網(wǎng)絡(luò)通信出現(xiàn)故障，重新向組播地址發(fā)送幀請(qǐng)求命令’R’，并重啟軟件電子狗。

③　依次接收來(lái)自每個(gè)發(fā)送端的RTP數(shù)據(jù)包，并根據(jù)IP地址和RTP包傳輸序號(hào)還原每幀視頻，直至收到視頻幀傳輸結(jié)束標(biāo)識(shí)0xFF。

2.3 SDL視頻顯示模塊

YUV格式在存儲(chǔ)方式上分為打包格式(Packed Format)和平面格式(Planner Format)，打包格式的Y、U、V三個(gè)分量連續(xù)交叉存儲(chǔ)，而平面格式的Y、U、V三個(gè)分量分開(kāi)存儲(chǔ)。實(shí)驗(yàn)中USB攝像頭采集的圖像格式是YUY2格式，而經(jīng)過(guò)拼接完成的圖像是YV12格式。YUY2格式是一種打包格式，以4:2:2方式打包，每個(gè)像素保留Y分量，而UV分量在水平方向上的采樣率僅為Y分量的1/2，即存儲(chǔ)順序?yàn)閇Y0 U0 Y1 V0] [Y2 U2 Y3 V2] ……[Y2n U2n Y2n+1 V2n]。YV12是一種平面格式，UV分量在水平方向和垂直方向上的采樣率均為Y分量的1/2。特殊地，YV12格式在UV提取時(shí)，需先將圖像劃分為若干個(gè)2 x 2的方陣，然后在每個(gè)方陣上提取一個(gè)U分量和一個(gè)V分量。例如，對(duì)于6x4的圖像，YV12的采樣方式如下圖所示，其存儲(chǔ)順序?yàn)閇Y0 Y1 Y2 Y3 Y4 Y5 Y6 Y7 Y8 Y9 Y10 Y11 Y12 Y13 Y14 Y15 Y16 Y17 Y18 Y19 Y20 Y21 Y22 Y23] [U0 U1 U2 U3 U4 U5] [V0 V1 V2 V3 V4 V5 V6]。[!--empirenews.page--]

YV12采樣方式示意圖

SDL支持FrameBuffer，利用SDL可以在Android和Linux上直接顯示YUY2和YV12格式的圖像，不需要經(jīng)過(guò)YUV格式到RGB格式的轉(zhuǎn)換。不同的是，標(biāo)準(zhǔn)Linux的FrameBuffer設(shè)備文件為/dev/fb0，而Android Linux的FrameBuffer設(shè)備文件是/dev/graphics/fb0。利用SDL顯示YUV格式圖像的流程包括：(1)初始化視頻設(shè)備;(2)設(shè)置視頻顯示模式;(3)創(chuàng)建YUV覆蓋層;(4)輪詢事件處理;(5)繪制YUV覆蓋層;(6)顯示YUV覆蓋層;(7)釋放YUV覆蓋層;(8)退出SDL。

3 ARM+DSP雙核視頻拼接模塊

3.1 Codec Engine雙核通信設(shè)計(jì)

Codec Engine是ARM和DSP通信的橋梁，采用遠(yuǎn)程過(guò)程調(diào)用(RPC)的思想。ARM端作為客戶端，DSP端作為服務(wù)器端，ARM和DSP之間的通信鏈路是共享內(nèi)存，通信協(xié)議是DSP Link。Codec Engine有專門的內(nèi)存管理驅(qū)動(dòng)CMEM來(lái)管理ARM和DSP之間的共享內(nèi)存，CMEM以內(nèi)存池或內(nèi)存堆的方式管理一個(gè)或者多個(gè)連續(xù)的物理塊內(nèi)存并提供地址轉(zhuǎn)換(虛擬地址和物理地址之間的轉(zhuǎn)換)功能。

Codec Engine有核心引擎接口和VISA接口。核心引擎接口包括引擎的初始化接口、引擎運(yùn)行狀態(tài)的控制接口和內(nèi)存的系統(tǒng)抽象層接口;VISA接口包括視頻編/解碼接口、音頻編/解碼接口、圖像編/解碼接口和語(yǔ)音編/解碼接口。VISA接口的使用分為VISA創(chuàng)建、VISA控制、VISA處理和VISA刪除四部分，圖3展示了通過(guò)VISA控制/處理的流程。

圖3 VISA 控制/處理示意圖

Codec Engine的使用分為創(chuàng)建應(yīng)用程序、實(shí)現(xiàn)Codec算法和集成Codec Server三部分。應(yīng)用程序運(yùn)行在ARM端，通過(guò)調(diào)用核心引擎接口和VISA接口與DSP進(jìn)行通信;對(duì)于符合XDM(eXpressDSP Digital Media)規(guī)范的Codec算法，Codec Engine的VISA接口不需要附加條件就能支持遠(yuǎn)端運(yùn)行，對(duì)于符合XDAIS(eXpressDSP Algorithm Interface Standard)規(guī)范的非XDM算法，必須提供Codec Engine的存根和骨架中間件才能支持遠(yuǎn)端運(yùn)行;Codec Server運(yùn)行在DSP端，負(fù)責(zé)管理調(diào)度不同的Codec算法。

車載分布式視頻監(jiān)控系統(tǒng)接收端使用視頻編碼接口(VIDENC_)實(shí)現(xiàn)ARM端調(diào)用DSP端基于SURF的圖像拼接算法。應(yīng)用程序的執(zhí)行流程如圖4所示。

圖4 車載分布式視頻監(jiān)控系統(tǒng)接收端應(yīng)用程序流程圖

3.2基于SURF的視頻拼接

系統(tǒng)采用SURF算法檢測(cè)特征點(diǎn)和描述特征點(diǎn)。SURF具有尺度和旋轉(zhuǎn)不變性，對(duì)光照和視點(diǎn)變換具有不錯(cuò)的魯棒性，并且經(jīng)過(guò)優(yōu)化后可以滿足實(shí)時(shí)性要求。根據(jù)特征點(diǎn)之間的歐氏距離進(jìn)行粗匹配，使用RANSAC(隨機(jī)一致性)方法去除錯(cuò)匹配點(diǎn)，計(jì)算圖像之間的透視變換矩陣，最終采用漸入漸出平均法融合圖像。

針對(duì)本系統(tǒng)，可以對(duì)算法進(jìn)行進(jìn)一步的優(yōu)化，提高系統(tǒng)的實(shí)時(shí)性。由于系統(tǒng)中攝像頭的位置相對(duì)固定，因而可以預(yù)先計(jì)算圖像之間的重疊位置，不需檢測(cè)完全沒(méi)有圖像重疊的區(qū)域;同時(shí)，由于攝像頭相對(duì)位置不變，圖像之間的透視變化矩陣不會(huì)變化，因此可以只計(jì)算一次透視變化矩陣，后續(xù)拼接使用第一次的透視變化矩陣，可進(jìn)一步提高實(shí)時(shí)性。

(1)SURF特征點(diǎn)檢測(cè)

SURF特征點(diǎn)檢測(cè)是在尺度空間中進(jìn)行的，并使用Hessian矩陣行列式值檢測(cè)特征點(diǎn)，尺度為σ的點(diǎn)X(x,y)的Hessian矩陣H(X,σ)定義如式(3-1)，其中Lxx (X,σ)，Lxy (X,σ)，Lyy (X,σ)為在尺度σ下的高斯函數(shù)的二階偏導(dǎo)數(shù)在圖像點(diǎn)X處的卷積。

SURF使用基于積分圖的盒型濾波器(box filter)近似此高斯卷積過(guò)程，圖3-2所示為9*9盒型濾波器對(duì)分別對(duì)x，y，xy方向的二維高斯濾波的近似。通過(guò)近似，將在點(diǎn)X(x,y)的二維高斯卷積轉(zhuǎn)化為對(duì)其周圍的加權(quán)計(jì)算過(guò)程，在此加權(quán)計(jì)算過(guò)程中，使用積分圖計(jì)算圖3-2中黑色矩形區(qū)域和白色矩形區(qū)域灰度值之和，將高斯濾波中的大量的乘法運(yùn)算轉(zhuǎn)換為簡(jiǎn)單的加減運(yùn)算。

設(shè)對(duì)x，y，xy方向的二維高斯卷積的近似分別用Dxx，Dyy，Dxy表示，則可以通過(guò)式(3-2)近似Hessian矩陣H(X,σ)行列式值，其中w通常取0.9。當(dāng)Det(H(X,σ))>0時(shí)，Dxx>0時(shí)，點(diǎn)X(x,y)為局部極小值點(diǎn);Dxxxx*Dyy-(w*Dxy)2 (3-2)

(2)SURF特征點(diǎn)描述

特征點(diǎn)描述主要分兩步：第一步是獲取特征點(diǎn)的主方向，主要目的是為了保證旋轉(zhuǎn)不變性。第二步是生成64維的特征點(diǎn)描述符，主要目的是描述特征點(diǎn)的特征。

為了獲取特征點(diǎn)的主方向，計(jì)算以特征點(diǎn)為中心，半徑為6σ(σ為特征點(diǎn)所在的尺度)內(nèi)的所有點(diǎn)在x，y方向的Harr小波響應(yīng)。并選取一個(gè)大小為60度的扇形窗口旋轉(zhuǎn)整個(gè)圓形區(qū)域，將窗口內(nèi)所有x，y方向的響應(yīng)值相加得到一個(gè)新矢量，最終以最長(zhǎng)的矢量所在的方向作為特征點(diǎn)的主方向。

特征點(diǎn)描述需要將坐標(biāo)軸旋轉(zhuǎn)到主方向上，并將以特征點(diǎn)為中心的邊長(zhǎng)為20σ的區(qū)域劃分為4×4個(gè)子窗口，每個(gè)子窗口分為5×5個(gè)采樣點(diǎn)，計(jì)算每個(gè)采樣點(diǎn)的沿主方向和垂直主方向的Harr小波響應(yīng)，記為d_x和d_y，最終生成一個(gè)4維矢量v=(∑dx,∑dy ,∑|dx|,∑|dy|)，并將其歸一化?？偣?×4個(gè)子窗口，生成64維的描述符。

3.3 SURF在DM3730上的移植和優(yōu)化

(1)SURF的移植

SURF算法實(shí)現(xiàn)基于OpenCV1.0,OpenCV庫(kù)針對(duì)x86架構(gòu)作了許多優(yōu)化，在DSP上的執(zhí)行效率難以得到保證。EMCV是一個(gè)可運(yùn)行在DSP上的OpenCV庫(kù)，但只實(shí)現(xiàn)了部分OpenCV的數(shù)據(jù)結(jié)構(gòu)和庫(kù)函數(shù)。因此，車載分布式視頻監(jiān)控系統(tǒng)需要擴(kuò)充EMCV庫(kù)，以支持SURF在DM3730上的運(yùn)行。擴(kuò)充的庫(kù)函數(shù)包括：cvAdd、cvAddWeighted、cvConvertScale、cvCvtColor、cvGEMM、cvInvert、cvMerge、cvResetImageROI、cvResize、cvSVD、cvSetImageROI、cvSplit、cvWarpPerspective。[!--empirenews.page--]

為了便于EMCV庫(kù)的擴(kuò)充和優(yōu)化，EMCV庫(kù)通過(guò)CCS(Code Composer Studio)軟件以lib靜態(tài)庫(kù)的形式提供給Codec算法使用，如下所示：

[package.bld]

packageti.sdo.ce.examples.codecs.videnc_mosaic.emcv{

}

[package.xs]

functiongetLibs(prog){

var name = null;

if (prog.build.target.isa == "64P") {

var name = "emcv.lib";

print(" will link with " + this.$name + ":" + name);

}

return (name);

}

此外，為了消除SURF對(duì)C++標(biāo)準(zhǔn)模板庫(kù)的依賴，車載分布式視頻監(jiān)控系統(tǒng)設(shè)計(jì)了專門的容器結(jié)構(gòu)和相應(yīng)的操作，主要代碼如下：

typedefstruct _Vector{

void *pdata; // 數(shù)據(jù)塊首地址

int count; // 數(shù)據(jù)塊元素?cái)?shù)目

int size; // 數(shù)據(jù)塊已用大小

int totalSize; // 數(shù)據(jù)塊總大小

}Vector;

#define PRE_CALLOC_SIZE 20 // 預(yù)分配元素個(gè)數(shù)

/* 添加nElem個(gè)元素，每個(gè)元素大小elSize */

intvector_pushback( Vector *pVector, intnElem, intelSize ){

int n = nElem> PRE_CALLOC_SIZE? nElem:PRE_CALLOC_SIZE;

if(pVector->size + nElem*elSizetotalSize ){

pVector->size += nElem*elSize;

pVector->count += nElem;

return 0;

}else{ // 預(yù)分配的內(nèi)存不足，需重新分配內(nèi)存

pVector->totalSize += n*elSize;

void *pNewData = (void*)realloc( pVector->pdata, pVector->totalSize );

if(pNewData ){

pVector->pdata = pNewData;

pVector->size += nElem*elSize;

pVector->count += nElem;

return 0;

}else{ // 內(nèi)存分配失敗

return -1;

}

}

}

/* 銷毀容器，釋放內(nèi)存 */

voidvector_destroy( Vector*pVector ){

if(pVector->pdata ){

free(pVector->pdata );

pVector->pdata = NULL;

}

pVector->size = pVector->count = pVector->totalSize = 0;

}

(2)SURF在DM3730上的優(yōu)化

SURF在DM3730上的優(yōu)化分為項(xiàng)目級(jí)優(yōu)化、指令級(jí)優(yōu)化和緩存優(yōu)化三個(gè)方面。項(xiàng)目級(jí)優(yōu)化是通過(guò)合理地選擇和配置相關(guān)的編譯器優(yōu)化選項(xiàng)，主要包括：調(diào)試模式選項(xiàng)(Debugging Model)、優(yōu)化等級(jí)選項(xiàng)(opt_level)、代碼大小選項(xiàng)(opt_for_sapce)、代碼速度選項(xiàng)(opt_for_speed)、程序級(jí)優(yōu)化(-op)等。為了最大限度地提高代碼的執(zhí)行效率，車載分布式視頻監(jiān)控系統(tǒng)選擇的編譯器優(yōu)化選項(xiàng)為-o3、-ms0、-mf5、-op2、-mt、-mh、-mw。指令級(jí)優(yōu)化包括選擇合適的數(shù)據(jù)類型，消除指令和數(shù)據(jù)之間的相關(guān)性，使用內(nèi)聯(lián)(intrinsic)函數(shù)以及改善軟件流水等。緩存優(yōu)化是將CPU近期訪問(wèn)過(guò)的數(shù)據(jù)或者程序放置在Cache中，以提高CPU的執(zhí)行速度。

4 測(cè)試結(jié)果及分析

圖6展示了車載分布式視頻監(jiān)控系統(tǒng)的拼接效果，表1比較了SURF和SIFT算法在DM3730和PC機(jī)上的拼接效率。從拼接效果可以看出，車載分布式視頻監(jiān)控系統(tǒng)能適應(yīng)圖像的平移、旋轉(zhuǎn)和縮放等特性。圖6中的兩幅待拼接的圖像存在明顯的旋轉(zhuǎn)特性，并且拼接完成的圖像有一定的縮放效果。從表1中可以看出，車載分布式視頻監(jiān)控系統(tǒng)在視頻采集、視頻傳輸和視頻顯示上總耗時(shí)約為257ms，遠(yuǎn)遠(yuǎn)小于視頻拼接所需時(shí)間3264ms。這是由于視頻拼接模塊使用了許多EMCV和OpenCV庫(kù)函數(shù)，它們?cè)贒M3730處理器上還有待進(jìn)一步被優(yōu)化。作為SIFT算法的加速版，SURF算法的執(zhí)行效率要遠(yuǎn)遠(yuǎn)大于SIFT算法的執(zhí)行效率。從本次測(cè)試結(jié)果看，在DM3730上，SURF算法的執(zhí)行效率是SIFT算法執(zhí)行效率的3.68倍左右;而在以Intel Core2 Duo T5870為處理器的PC機(jī)上，SURF算法的執(zhí)行效率是SIFT算法執(zhí)行效率的1.40倍左右。

在攝像頭相對(duì)位置固定情況下，圖像之間的透視變化矩陣固定，因此只需計(jì)算一次透視變化矩陣，后續(xù)的圖像拼接只需進(jìn)行圖像配準(zhǔn)和融合。表2中列出了DM3730上SURF算法的時(shí)間組成，其中SURF算法透視變換矩陣計(jì)算時(shí)間占95%以上，實(shí)際的圖像拼接時(shí)間為圖像配準(zhǔn)和如何時(shí)間，平均時(shí)間約為66ms。

結(jié)語(yǔ)

本文從視頻采集、視頻傳輸、視頻拼接和視頻顯示等四個(gè)方面詳細(xì)闡述了基于Android和DM3730的汽車分布式視頻監(jiān)控系統(tǒng)的設(shè)計(jì)原理和優(yōu)勢(shì)。從測(cè)試結(jié)果看，車載分布式視頻監(jiān)控系統(tǒng)基本上能達(dá)到實(shí)時(shí)采集、實(shí)時(shí)傳輸、實(shí)時(shí)顯示，經(jīng)過(guò)優(yōu)化后，圖像拼接的效率基本能滿足實(shí)時(shí)性要求，但系統(tǒng)整體性能還有待提高，可以采用多核處理器代替單核處理器，進(jìn)一步提高系統(tǒng)的實(shí)時(shí)性。