0 引言

    隨著高清影像與手持?jǐn)?shù)碼產(chǎn)品的普及，數(shù)字影像技術(shù)受到了產(chǎn)業(yè)界的重視，因數(shù)字影像攜帶大容量信息且引起豐富的創(chuàng)造潛能。高清、高幀率影像不僅能展現(xiàn)更高的畫(huà)面質(zhì)量，還能提升畫(huà)面的連續(xù)性，在網(wǎng)絡(luò)監(jiān)控、醫(yī)療等領(lǐng)域有廣闊的前景。通常，數(shù)字影像采集設(shè)備用成像芯片將光學(xué)圖像轉(zhuǎn)換為電荷，成像芯片決定影像質(zhì)量，占相機(jī)成本的10%~25%?？紤]到成本、體積及硬件工藝，多數(shù)影像采集設(shè)備使用覆蓋有一層色彩濾鏡陣列的單個(gè)成像芯片。每個(gè)感光單元只能取樣一種色彩，其余兩種顏色值需用相鄰單元的取樣值進(jìn)行插值計(jì)算得到。這種色彩插值就是去馬賽克，是數(shù)字影像采集流水線的一個(gè)關(guān)鍵環(huán)節(jié)，在高幀率、高清圖像處理應(yīng)用中有重要價(jià)值。

    本設(shè)計(jì)基于異構(gòu)計(jì)算實(shí)現(xiàn)了一個(gè)自適應(yīng)去馬賽克算法的OpenCL代碼，并在AMD Bald Eagle和AMD FirePro W8100（或ES8950 MXM）GPU組成的異構(gòu)計(jì)算平臺(tái)上進(jìn)行了測(cè)試。據(jù)了解，目前還沒(méi)有異構(gòu)平臺(tái)的去馬賽克并行代碼。深度優(yōu)化的代碼充分發(fā)揮了異構(gòu)平臺(tái)的架構(gòu)優(yōu)勢(shì)以及FirePro W8100的浮點(diǎn)運(yùn)算能力和高GFLOPS/J特點(diǎn)。整個(gè)系統(tǒng)具有低的計(jì)算耗時(shí)，處理圖像的速率超過(guò)了100 f/s，每幀的像素?cái)?shù)量是1 920×1 080。實(shí)驗(yàn)數(shù)據(jù)證明該方案能滿足醫(yī)療、安監(jiān)等領(lǐng)域?qū)Ω邘屎透咔鍞?shù)字影像的需求。

1 圖像插值算法和異構(gòu)計(jì)算

1.1 圖像去馬賽克算法

    圖像去馬賽克算法是數(shù)碼影像產(chǎn)品里的一項(xiàng)關(guān)鍵技術(shù)，其性能優(yōu)劣直接影響著圖像質(zhì)量，性能不好的算法會(huì)使重建圖像有彩色馬賽克或拉鏈?zhǔn)д娴然儭０词欠窭每臻g相關(guān)性，文獻(xiàn)[1]將現(xiàn)有的算法分為兩類(lèi)——非自適應(yīng)插值法（如最近鄰域復(fù)制、雙線性插值和三次樣條插值）和利用相關(guān)性的插值法。前一類(lèi)算法易于實(shí)現(xiàn)，可以在圖像的平滑區(qū)域得到滿意的插值效果，但在目標(biāo)邊緣等高頻區(qū)域易引起插值畸變。后一類(lèi)方法利用相關(guān)性實(shí)現(xiàn)插值，相關(guān)性包括每個(gè)色彩通道內(nèi)像素間的空間相關(guān)性和多通道間的色彩值相關(guān)性。第二類(lèi)算法能得到高質(zhì)量的重建圖像，但是計(jì)算復(fù)雜度高。沒(méi)有專(zhuān)用加速計(jì)算芯片的支持，數(shù)字影像采集設(shè)備很難實(shí)時(shí)運(yùn)行后一類(lèi)算法。本文采用的Adaptive Homogeneity-Directed De-Mosaicking（AHDDM）屬于利用相關(guān)性的插值算法^[2]。該算法適于處理以Bayer色彩濾波陣列模式采集到的圖像，圖1是該算法的主要計(jì)算步驟流程。雖然這些步驟需要大量的浮點(diǎn)運(yùn)算和復(fù)雜的數(shù)值計(jì)算，但是適于用并行計(jì)算代碼實(shí)現(xiàn)加速。

1.2 異構(gòu)計(jì)算

    傳統(tǒng)的圖像處理平臺(tái)用CPU，系統(tǒng)運(yùn)算能力的提升受限于因提高CPU工作頻率引起的功耗的顯著增加。雖然CPU的同構(gòu)并行和分布系統(tǒng)能提升運(yùn)算能力，但其提升幅度不能隨著處理器數(shù)量線性增長(zhǎng)。在這些系統(tǒng)上，即便得到成熟的開(kāi)發(fā)經(jīng)驗(yàn)、編程語(yǔ)言、算法和調(diào)試工具等手段的協(xié)助，開(kāi)發(fā)圖像處理軟件也是一項(xiàng)困難的工作。異構(gòu)計(jì)算技術(shù)產(chǎn)生于80年代中期，主要指使用不同類(lèi)型指令集、體系架構(gòu)的計(jì)算單元組成混合系統(tǒng)的一種計(jì)算方式。常見(jiàn)的計(jì)算單元包括兼容X86指令集的多核CPU、GPU、FPGA、DSP、音頻/視頻處理等專(zhuān)用集成電路（ASIC）^[3-4]。由于異構(gòu)計(jì)算能經(jīng)濟(jì)、有效地配置計(jì)算資源，提升資源利用率和可擴(kuò)展性，該技術(shù)已成為并行/分布計(jì)算領(lǐng)域中的一個(gè)研究熱點(diǎn)。異構(gòu)平臺(tái)通常由多核CPU和GPU組成。

1.3 AMD GPU

    在2012年以前，AMD 的GPU架構(gòu)采用VLIW4作為計(jì)算單元的指令格式，這使GPU適用于圖像渲染和3D圖形運(yùn)算。通常，通用計(jì)算的數(shù)據(jù)有復(fù)雜的結(jié)構(gòu)，這些數(shù)據(jù)結(jié)構(gòu)很難被歸并到有限的類(lèi)型之中，因此舊架構(gòu)的GPU芯片難以高效地完成通用并行計(jì)算或合理地配置資源。從2012年開(kāi)始，AMD 發(fā)布的GPU芯片采用了新架構(gòu)GCN^[5]，如圖2所示。GCN架構(gòu)不僅支持渲染和3D圖形計(jì)算，還支持通用計(jì)算和OpenCL 1.2標(biāo)準(zhǔn)。

    GCN架構(gòu)的核心特點(diǎn)表現(xiàn)在兩個(gè)方面。首先，該架構(gòu)用了新的CU結(jié)構(gòu)和指令集。每個(gè)CU有4個(gè)獨(dú)立的SIMD向量處理器和向量寄存器，還有一個(gè)標(biāo)量處理器和8 KB寄存器，用于減少向量計(jì)算的冗余計(jì)算。除了私有資源，4個(gè)SIMD共享前端、分支單元和數(shù)據(jù)緩存。這些設(shè)計(jì)使得一個(gè)CU能支持多達(dá)2 560 個(gè)線程。其次，GCN架構(gòu)還將改變擴(kuò)展到整個(gè)系統(tǒng)，如GCN架構(gòu)采用分級(jí)緩存。由一個(gè)向量數(shù)據(jù)讀取指令引發(fā)的64個(gè)存儲(chǔ)訪問(wèn)會(huì)被合并成一個(gè)訪問(wèn)。合并機(jī)制將讀取同一個(gè)cache line里的數(shù)據(jù)合并為一次訪問(wèn)，這能顯著地降低片外存儲(chǔ)器的讀取次數(shù)。數(shù)據(jù)存儲(chǔ)采用了不同于讀取的合并方式。在合并存儲(chǔ)器讀取請(qǐng)求之后，數(shù)據(jù)將被送至一級(jí)數(shù)據(jù)緩存，即分級(jí)緩存的第一級(jí)。如果CU需要的數(shù)據(jù)不在一級(jí)緩存，那么CU將通過(guò)開(kāi)關(guān)矩陣訪問(wèn)二級(jí)緩存。二級(jí)緩存有多個(gè)bank，采用交織尋址方式，各bank通過(guò)一個(gè)64位雙通道存儲(chǔ)控制器連接到片外存儲(chǔ)器。GCN分級(jí)存儲(chǔ)是一個(gè)合并讀寫(xiě)的緩存系統(tǒng)，支持虛擬內(nèi)存和原子操作，進(jìn)而支持GPU和CPU間的數(shù)據(jù)零拷貝。

1.4 OpenCL

    通常，硬件廠商僅提供支持自身芯片的編程模型和工具，所以難用一種風(fēng)格的編程語(yǔ)言實(shí)現(xiàn)異構(gòu)編程。此外，將不同設(shè)備作為統(tǒng)一的計(jì)算單元來(lái)處理是非常困難的。為解決該問(wèn)題，OpenCL通過(guò)一套機(jī)制實(shí)現(xiàn)獨(dú)立于硬件的軟件開(kāi)發(fā)環(huán)境，還能支持多級(jí)別的并行計(jì)算和不同設(shè)備的并行特性，將高級(jí)語(yǔ)言的代碼有效地映射到由CPU、GPU和其他芯片組成的系統(tǒng)上^[6]。OpenCL定義了運(yùn)行時(shí)系統(tǒng)管理資源，將不同類(lèi)型的硬件結(jié)合在同種執(zhí)行環(huán)境中，用來(lái)支持動(dòng)態(tài)平衡計(jì)算、功耗及其他資源^[7]。圖3示意了平臺(tái)模型和執(zhí)行模型間的關(guān)系。

2 OpenCL代碼設(shè)計(jì)及優(yōu)化

    本文用OpenCL 1.2標(biāo)準(zhǔn)設(shè)計(jì)GPU代碼，實(shí)現(xiàn)一個(gè)高復(fù)雜度的自適應(yīng)去馬賽克算法。因?yàn)樵撍惴▽?duì)每個(gè)像素進(jìn)行多次插值、濾波和非線性映射等操作，所以這個(gè)算法需要大量的浮點(diǎn)運(yùn)算以及數(shù)值計(jì)算，屬于數(shù)據(jù)密集型應(yīng)用，適合于GPU實(shí)現(xiàn)。為高速實(shí)現(xiàn)該算法，OpenCL代碼必須充分利用GPU的計(jì)算資源，如高速浮點(diǎn)運(yùn)算能力。目標(biāo)異構(gòu)平臺(tái)以CPU為核心，包含一個(gè)或多個(gè)OpenCL設(shè)備，這要求不同架構(gòu)的微處理器同時(shí)運(yùn)行不同性質(zhì)和內(nèi)容的計(jì)算任務(wù)，因此代碼應(yīng)同時(shí)進(jìn)行數(shù)據(jù)傳輸和計(jì)算，以利于整個(gè)系統(tǒng)高速地處理數(shù)據(jù)幀序列。

    OpenCL代碼的主要技術(shù)特點(diǎn)如下所述。在代碼加速方面，優(yōu)化了中值濾波和線性濾波的計(jì)算流程，優(yōu)化了片外存儲(chǔ)數(shù)據(jù)的訪問(wèn)。設(shè)備代碼還采用OpenCL內(nèi)建函數(shù)，加速了立方根等數(shù)值計(jì)算函數(shù)，這顯著地降低了處理器時(shí)間。軟件優(yōu)化了數(shù)據(jù)的存儲(chǔ)布局，降低了讀寫(xiě)數(shù)據(jù)次數(shù)。部分優(yōu)化方法的說(shuō)明可參考文獻(xiàn)[7-8]。在異構(gòu)加速方面，軟件創(chuàng)建了兩個(gè)命令隊(duì)列，分別控制OpenCL設(shè)備完成圖像處理和主機(jī)與設(shè)備間的數(shù)據(jù)傳輸。相比于單命令隊(duì)列控制OpenCL設(shè)備的計(jì)算和通信，新做法隱藏了數(shù)據(jù)傳輸，進(jìn)一步提高了每幀數(shù)據(jù)的處理速度。軟件采用了兩個(gè)事件對(duì)象同步兩個(gè)命令隊(duì)列。這種方式通過(guò)交替地創(chuàng)建和釋放事件對(duì)象，有效地避免了不同隊(duì)列里的命令在任一個(gè)時(shí)刻處理同一幀數(shù)據(jù)，保證了數(shù)據(jù)一致性。下面分別介紹這些代碼部分的設(shè)計(jì)。

2.1 軟件流程設(shè)計(jì)和描述

    按照OpenCL 1.2標(biāo)準(zhǔn)，采用主機(jī)和OpenCL設(shè)備協(xié)作實(shí)現(xiàn)AHDDM算法。主機(jī)代碼按照一個(gè)指定順序啟動(dòng)設(shè)備執(zhí)行設(shè)備代碼，完成平臺(tái)和設(shè)備信息的獲取、設(shè)備選擇、各種對(duì)象創(chuàng)建、主機(jī)和設(shè)備間通信、設(shè)備代碼的輸入?yún)?shù)配置和資源釋放。設(shè)備完成圖像處理計(jì)算，對(duì)輸入數(shù)據(jù)進(jìn)行插值和濾波，得到重建結(jié)果。在圖像處理中，水平/豎直方向插值、homogeneity計(jì)算、中值濾波和色彩空間轉(zhuǎn)換需要大量運(yùn)算。下面概略地介紹這些算法步驟。

2.1.1 插值

    對(duì)于一幅輸入圖像，AHDDM算法用一個(gè)像素的周邊像素值分布估計(jì)出該點(diǎn)缺失的信息，對(duì)水平插值和豎直插值結(jié)果進(jìn)行了選擇性組合。水平插值過(guò)程是：(1)求像素RGB值的和，存于矩陣X中；(2)在處理G通道時(shí)，對(duì)應(yīng)于G Mask的像素取矩陣X的值，對(duì)應(yīng)于R/B Mask的像素取矩陣X水平方向的鄰近4個(gè)值的加權(quán)平均；(3)在處理R和B通道時(shí)，輸出像素取以其為中心的3×3窗口內(nèi)所有R/B Mask像素的平均值。豎直插值過(guò)程是：除G通道R/B Mask下的像素取矩陣X豎直方向的最近4個(gè)值的計(jì)算結(jié)果以外，其余與水平插值相同。

2.1.2 計(jì)算Homogeneity矩陣

    該算法將水平插值和豎直插值得到的圖像轉(zhuǎn)換成LAB格式，并求出這兩張LAB圖像的亮度差和色彩差。隨后根據(jù)這兩個(gè)差值矩陣，OpenCL設(shè)備計(jì)算出水平插值和豎直插值的同質(zhì)矩陣H_x和H_y；接著對(duì)這兩個(gè)矩陣?yán)锏臄?shù)據(jù)進(jìn)行平滑處理。根據(jù)平滑結(jié)果，OpenCL設(shè)備合并水平插值圖像和豎直插值圖像，每個(gè)像素的取值判據(jù)是選擇其在H_x/H_y較大的像素值。

2.1.3 中值濾波

    合并后的插值圖像需要進(jìn)行中值濾波，以保證重建質(zhì)量。在R和B通道，每個(gè)像素取其相鄰的8個(gè)像素的中值濾波結(jié)果；在G通道里，每個(gè)像素取其上下左右4個(gè)相鄰的像素的中值濾波結(jié)果。中值計(jì)算需先將輸入的數(shù)據(jù)按照升序或降序排列，再輸出中間位置上的那個(gè)數(shù)值。當(dāng)輸入奇數(shù)個(gè)數(shù)據(jù)時(shí)，計(jì)算結(jié)果將是排序后的序列中間的數(shù)據(jù)；當(dāng)輸入偶數(shù)個(gè)數(shù)據(jù)時(shí)，計(jì)算結(jié)果將是排序后的序列中間的兩個(gè)數(shù)據(jù)的平均值。自適應(yīng)算法用兩次中值濾波，以得到較好的濾波效果。

2.1.4 色彩空間轉(zhuǎn)換

    RGB和CIELAB是常用的顏色空間。RGB便于建模物理設(shè)備的輸出，但不適合描述人類(lèi)視覺(jué)感知。CIELAB具有視覺(jué)上的均勻性，接近于人類(lèi)的視覺(jué)感知，即色彩值的變化和視覺(jué)感知到的變化程度是一致的^[9]。RGB和CIELAB之間的色彩值轉(zhuǎn)換需要分兩步進(jìn)行，即先規(guī)范化RGB值到0~1之間，用XYZ顏色空間作中間層；再用一組非線性變換得到CIELAB值^[10]。

    轉(zhuǎn)換公式顯示CIELAB轉(zhuǎn)換需要浮點(diǎn)型運(yùn)算，雖然可截取浮點(diǎn)計(jì)算結(jié)果的整數(shù)部分換取計(jì)算速度的增加，但是損失了計(jì)算精度。因?yàn)镽GB轉(zhuǎn)換CIELAB需要較多的數(shù)值計(jì)算，所以快速轉(zhuǎn)換是OpenCL代碼設(shè)計(jì)的一個(gè)重點(diǎn)。本文用一個(gè)3×3矩陣和一個(gè)1×3向量的浮點(diǎn)乘法實(shí)現(xiàn)規(guī)范化計(jì)算，用OpenCL 1.2標(biāo)準(zhǔn)的內(nèi)建立方根等函數(shù)實(shí)現(xiàn)非線性數(shù)值計(jì)算，用三元運(yùn)算符而不是條件指令加快非線性轉(zhuǎn)換中的流程控制。

2.2 并行圖像處理和數(shù)據(jù)通信

    本文用單個(gè)命令隊(duì)列實(shí)現(xiàn)單幅圖像的插值處理，用兩個(gè)命令隊(duì)列處理一個(gè)幀序列，隱藏了數(shù)據(jù)傳輸時(shí)間。代碼采用任務(wù)并行的方式，同步地完成圖像處理和數(shù)據(jù)通信。主機(jī)代碼用一個(gè)命令隊(duì)列里的命令啟動(dòng)OpenCL設(shè)備執(zhí)行設(shè)備代碼，用另一個(gè)命令隊(duì)列中的命令去控制設(shè)備內(nèi)存和主機(jī)內(nèi)存之間的數(shù)據(jù)通信。系統(tǒng)使用兩個(gè)事件對(duì)象同步兩個(gè)命令隊(duì)列的命令，通過(guò)交替地監(jiān)測(cè)兩個(gè)事件對(duì)象建立和釋放的返回值，安排兩個(gè)命令隊(duì)列中的命令讀寫(xiě)不同的存儲(chǔ)位置，免除了兩個(gè)隊(duì)列里的命令讀寫(xiě)相同的存儲(chǔ)位置。

2.3 存儲(chǔ)空間配置

    根據(jù)算法流程，在開(kāi)始插值計(jì)算前，需鏡像擴(kuò)展原始圖像的邊緣部分。其次，一些計(jì)算步驟訪問(wèn)多個(gè)相鄰的像素，這需要條件指令限定并行線程的處理范圍，否則邊緣像素的重建結(jié)果將會(huì)有明顯偏差。軟件采取了圖像補(bǔ)零法，填補(bǔ)寬度是各步驟的最大補(bǔ)零長(zhǎng)度，這利于合并掉一些條件指令，減少計(jì)算時(shí)間。如果原始圖像的尺寸是M×N，鏡像擴(kuò)展圖像的尺寸是H×W，則輸入和輸出圖像的尺寸是M×N，中間結(jié)果的尺寸均是(H+2×P)×(W+2×P)，其中P是補(bǔ)零寬度，取2和delta(homogeneity函數(shù)的參數(shù))的最大值。在本文的實(shí)驗(yàn)中，delta默認(rèn)取值為3，所以P取delta值。最后，代碼將擴(kuò)展圖像的寬度和高度取為16的整數(shù)倍，以提高數(shù)據(jù)訪問(wèn)效率。在實(shí)驗(yàn)中，原始圖像和重建圖像的尺寸是1 920×1 080像素，中間結(jié)果是1 952×1 104像素。

3 實(shí)驗(yàn)及討論

    本文的異構(gòu)計(jì)算平臺(tái)的配置如下：硬件平臺(tái)由AMD Bald Eagle和AMD FirePro W8100^[11](或ES8950 MXM)組成，軟件開(kāi)發(fā)環(huán)境是Win7、AMD Catalyst 13.11以上版本和AMD APP SDK 2.8^[12]，編程語(yǔ)言及版本號(hào)是VC2010和OpenCL 1.2 C。圖4是原始RGB圖像、模擬數(shù)據(jù)和插值重建圖像。三幅圖像的尺寸均為1 920×1 080像素，有3個(gè)圖像通道。按照Bayer模式，對(duì)原始圖進(jìn)行采樣得到模擬圖，模擬圖偏綠。對(duì)比原始圖像和重建結(jié)果，可看出重建結(jié)果非常接近于原始圖像，而且差別很小。該異構(gòu)平臺(tái)的重建圖像與CPU代碼的計(jì)算結(jié)果不存在明顯差異，區(qū)域交界處的虛假色塊和拉鏈等失真被抑制和消除，細(xì)節(jié)得到了保留。

    在Intel i7平臺(tái)上，該算法的MATLAB代碼的運(yùn)行時(shí)間約為7 s。圖5是 FirePro W8100的一段工作時(shí)序，顯示了兩個(gè)命令隊(duì)列的運(yùn)行情況，其中Queue0 和Queue1分別對(duì)應(yīng)于數(shù)據(jù)處理命令隊(duì)列和通信命令隊(duì)列。該圖顯示出交疊的數(shù)據(jù)通信和數(shù)據(jù)處理命令節(jié)省了GPU計(jì)算時(shí)間。AMD Bald Eagle APU處理器集成有X86 CPU內(nèi)核和GPU內(nèi)核，但其GPU核的計(jì)算單元數(shù)量遠(yuǎn)小于W8100的計(jì)算單元數(shù)量。因?yàn)橛靡粋€(gè)命令隊(duì)列完成數(shù)據(jù)通信和執(zhí)行處理算法，所以該GPU核大約用67 ms完成單幅圖像的去馬賽克處理，如圖6所示。表1列出了W8100處理各步驟的耗時(shí)，總和約為6.22 ms，因?yàn)樵O(shè)備啟動(dòng)命令需要時(shí)間，所以每一幅圖像的插值處理大約用8.6 ms。兩種工作時(shí)序的對(duì)比顯示出多命令隊(duì)列方式能更高效地使用OpenCL設(shè)備的計(jì)算資源。

    除了上述的代碼優(yōu)化方法以外，OpenCL代碼仍有進(jìn)一步提升性能的方式，如使用三維查找表插值法提高RGB值轉(zhuǎn)換為CIELAB值的速度。

4 小結(jié)

    按照OpenCL 1.2標(biāo)準(zhǔn)，本文開(kāi)發(fā)了自適應(yīng)去馬賽克并行代碼，在AMD Bald Eagle和AMD FirePro W8100 GPU組成的異構(gòu)系統(tǒng)上進(jìn)行了驗(yàn)證。AMD FirePro W8100能滿足100 f/s的圖像處理，圖像尺寸達(dá)到了1 920×1 080像素，每個(gè)像素有RGB值。本文的實(shí)驗(yàn)證明異構(gòu)計(jì)算是一種適于高清影像和大尺幅圖像處理的有效方案。

參考文獻(xiàn)

[1] LI X.Image demosaicking：a systematic survey[C].Proc.of SPIE Electronic Imaging Conference，2008.

[2] HIRAKAWA K.Adaptive homogeneity-directed demosaicing algorithm[J].IEEE Trans.on Image Processing，2005，14(3)：360-369.

[3] HSA Foundation.Heterogeneous system architecture：A technical review presentation[EB/OL].(2012)[2015].Available：http：//www.slideshare.net/hsafoundation/hsa10-whitepaper.

[4] AMD Inc.AMD and HSA：A new era of vivid digital experiences website[EB/OL].(2013)[2016].Available：http：//www.amd.com/us/products/technologies/hsa/Pages/hsa.aspx#1.

[5] AMD Inc.AMD Graphics Cores Next(GCN) architecture[EB/OL].(2012)[2016].Available：http：//www.amd.com/jp/Documents/GCN Architecture whitepaper.pdf.

[6] Khronos OpenCL Working Group.The OpenCL specification 1.2[EB/OL].(2011)[2016].Available：http：//www.khronos.org/registry/cl/specs/opencl-1.2.pdf.

[7] MUNSHI A.OpenCL programming guide for optimization techniques[M].Addison-Wesley Professional，2011.

[8] AMD Inc.ATI streaming SDK OpenCL programming guide 4.2[EB/OL].(2013)[2016].Available：http：//developer.amd.com/wordpress/media/2013/07/AMD_Accelerated_Parallel_Processing_OCL_Programming_Guide-2013-06-21.pdf.

[9] BILLMEYER F W，SALTZMAN J M.Principles of color technology[M].2nd ed.，John Wiley & Sons，Inc.，New York，1981.

[10] SCHALLER N C.Color conversion algorithms[EB/OL].(2015)[2016].Available：http：//www.cs.rit.edu/~ncs/color/t_convert.html.

[11] AMD Inc.FirePro datasheet[EB/OL].(2015)[2016].Available：http：//www.amd.com/Documents/FirePro-W8100-Data-Sheet.pdf.

[12] AMD Inc.AMD accelerated parallel processing software development Kit[EB/OL].(2016)[2016].Available：http：//developer.amd.com/sdks/amdappsdk/.