Camera 圖像處理原理分析

Camera 圖像處理原理分析 2011-06-13 20:03:41

分類：

1         前言

做爲拍照手機的核心模塊之一，camera sensor效果的調整，涉及到衆多的參數，如果對基本的光學原理及sensor軟/硬件對圖像處理的原理能有深入的理解和把握的話，對我們的工作將會起到事半功倍的效果。否則，缺乏了理論的指導，只能是憑感覺和經驗去碰，往往無法準確的把握問題的關鍵，不能掌握sensor調試的核心技術，無法根本的解決問題。

所以，這裏筆者結合自己出於對攝影的愛好所學習的一些圖像處理相關的原理，試圖通過分析一些與Sensor圖像處理相關的因素，和大家分享一下自己的一些理解，共同探討，共同學習進步。

2         色彩感應及校正

2.1        原理

人眼對色彩的識別，是基於人眼對光線存在三種不同的感應單元，不同的感應單元對不同波段的光有不同的響應曲線的原理，通過大腦的合成得到色彩的感知。 一般來說，我們可以通俗的用RGB三基色的概念來理解顏色的分解和合成。

 

理論上，如果人眼和sensor對光譜的色光的響應，在光譜上的體現如下的話，基本上對三色光的響應，相互之間不會發生影響，沒有所謂的交叉效應。

 

但是，實際情況並沒有如此理想，下圖表示了人眼的三色感應系統對光譜的響應情況。可見RGB的響應並不是完全獨立的。

下圖則表示了某Kodak相機光譜的響應。可見其與人眼的響應曲線有較大的區別。

2.2        對sensor的色彩感應的校正

既然我們已經看到sensor對光譜的響應，在RGB各分量上與人眼對光譜的響應通常是有偏差的，當然就需要對其進行校正。不光是在交叉效應上，同樣對色彩各分量的響應強度也需要校正。通常的做法是通過一個色彩校正矩陣對顏色進行一次校正。

1

該色彩校正的運算通常是由sensor模塊集成或後端的ISP完成，軟件通過修改相關寄存器得到正確的校正結果。值得注意的一點是，由於RGB -> YUV的轉換也是通過一個3*3的變換矩陣來實現的，所以有時候這兩個矩陣在ISP處理的過程中會合併在一起，通過一次矩陣運算操作完成色彩的校正和顏色空間的轉換。

3         顏色空間

3.1        分類

實際上顏色的描述是非常複雜的，比如RGB三基色加光系統就不能涵蓋所有可能的顏色，出於各種色彩表達，以及色彩變換和軟硬件應用的需求，存在各種各樣的顏色模型及色彩空間的表達方式。這些顏色模型，根據不同的劃分標準，可以按不同的原則劃分爲不同的類別。

匹配任意可見光所需的三原色光比例曲線

 

對於sensor來說，我們經常接觸到的色彩空間的概念，主要是RGB , YUV這兩種（實際上，這兩種體系包含了許多種不同的顏色表達方式和模型，如sRGB, Adobe RGB, YUV422, YUV420 …）, RGB如前所述就是按三基色加光系統的原理來描述顏色，而YUV則是按照 亮度，色差的原理來描述顏色。

3.1.1                RGB <-> YUV的轉換

不比其它顏色空間的轉換有一個標準的轉換公式，因爲YUV在很大程度上是與硬件相關的，所以RGB與YUV的轉換公式通常會多個版本，略有不同。

 

常見的公式如下：

Y=0.30R+0.59G+0.11B
U=0.493(B－Y) = －0.15R－0.29G+0.44B
V=0.877(R－Y) = 0.62R－0.52G－0.10B

 

但是這樣獲得的YUV值存在着負值以及取值範圍上下限之差不爲255等等問題，不利於計算機處理，所以根據不同的理解和需求，通常在軟件處理中會用到各種不同的變形的公式，這裏就不列舉了。

體現在Sensor上，我們也會發現有些Sensor可以設置YUV的輸出取值範圍。原因就在於此。

從公式中，我們關鍵要理解的一點是，UV 信號實際上就是藍色差信號和紅色差信號，進而言之，實際上一定程度上間接的代表了藍色和紅色的強度，理解這一點對於我們理解各種顏色變換處理的過程會有很大的幫助。

1.1        白平衡

1.1.1          色溫

色溫的定義：將黑體從絕對零度開始加溫，溫度每升高一度稱爲1開氏度(用字母K來表示)，當溫度升高到一定程度時候，黑體便輻射出可見光，其光譜成份以及給人的感覺也會着溫度的不斷升高發生相應的變化。於是，就把黑體輻射一定色光的溫度定爲發射相同色光光源的色溫。

常見光源色溫：

光源                        色溫（K）

    鎢絲燈（白熾燈）            2500-3200k

    碳棒燈                      4000-5500k

    熒光燈（日光燈，節能燈）   4500-6500k

氙燈                        5600 k

炭精燈                      5500～6500k

    日光平均                    5400k

    有云天氣下的日光            6500-7000k

    陰天日光                    12000-18000k

 

隨着色溫的升高，光源的顏色由暖色向冷色過渡，光源中的能量分佈也由紅光端向藍光端偏移。

值得注意的是，實際光源的光譜分佈各不相同，而色溫只是代表了能量的偏重程度，並不反映具體的光譜分佈，所以即使相同色溫的光源，也可能引起不同的色彩反應。

人眼及大腦對色溫有一定的生理和心理的自適應性，所以看到的顏色受色溫偏移的影響較小，而camera的sersor沒有這種能力，所以拍出來的照片不經過白平衡處理的話，和人眼看到的顏色會有較大的偏差（雖然人眼看到的和白光下真實的色彩也有偏差）。

太陽光色溫隨天氣和時間變化的原因，與不同頻率光的折射率有關：

波長長的光線，折射率小，透射能力強，波長短的光線，折射率大，容易被散射，折射率低，這也就是爲什麼交通燈用紅色，防霧燈通常是黃色，天空爲什麼是藍色的等等現象的原因。

知道了這一點，太陽光色溫變化的規律和原因也就可以理解和分析了，留給大家自己思考。

 

 

1.1.1          色溫變化時的色彩校正

所以從理論上可以看出，隨着色溫的升高，要對色溫進行較正，否則，物體在這樣的光線條件下所表現出來的顏色就會偏離其正常的顏色，因此需要降低sensor對紅色的增益，增加sersor對藍光的增益。同時在調整參數時一定程度上要考慮到整體亮度的要保持大致的不變，即以YUV來衡量時，Y值要基本保持不變，理論上認爲可以參考RGB->YUV變換公式中，RGB三分量對Y值的貢獻，從而確定RGAIN和BGAIN的變化的比例關係。但實際情況比這還要複雜一些，要考慮到不同sensor對R,B的感光的交叉影響和非線性，所以最佳值可能和理論值會有一些偏差。

1.1.2          自動白平衡原理

1.1.2.1        原理

自動白平衡是基於假設場景的色彩的平均值落在一個特定的範圍內，如果測量得到結果偏離該範圍，則調整對應參數，校正直到其均值落入指定範圍。該處理過程可能基於YUV空間，也可能基於RGB空間來進行。對於Sensor來說，通常的處理方式是通過校正R/B增益，使得UV值落在一個指定的範圍內。從而實現自動白平衡。

 

1.1.2.2        特殊情況的處理

在自動白平衡中，容易遇到的問題是，如果拍攝的場景，排除光線色溫的影響，其本身顏色就是偏離平均顏色值的，比如大面積的偏向某種顏色的圖案如：草地，紅旗，藍天等等，這時候，強制白平衡將其平均顏色調整到灰色附近，圖像顏色就會嚴重失真。

因此，通常的做法是：在處理自動白平衡時，除了做爲目標結果的預期顏色範圍外，另外再設置一對源圖像的顏色範圍闕值，如果未經處理的圖像其顏色均值超出了該闕值的話，根本就不對其做自動白平衡處理。由此保證了上述特殊情況的正確處理。

可見，這兩對闕值的確定對於自動白平衡的效果起着關鍵性的作用。

1.1.3          某平臺的例子

英文代碼              中文界面       色溫       色溫       RGAIN, GGAIN,   BGAIN

cloud           陰天        7500k   0x1D4C, 0x00CD, 0x0085, 0x0080

daylight        日光        6500k   0x1964, 0x00A3, 0x0080, 0x0088

INCANDESCENCE   白熱光    5000k   0x1388, 0x00A5, 0x0080, 0x0088

FLUORESCENT     日光燈      4400k   0x1130, 0x0098, 0x0080, 0x00A8

TUNGSTEN        鎢絲燈      2800k   0x0AF0, 0x0080, 0x0081, 0x00A4

 

可以看到隨着色溫的升高，其變化規律基本符合上節中的理論分析。不過這裏多數參數與理論值都有一些偏差，其中日光燈的色溫參數設置與理論值有較大的偏差，實際效果也證明該日光燈的參數設置使得在家用日光燈環境下拍攝得到的照片顏色偏藍。修改其參數後實拍效果明顯改善。（再查一些資料可以看到通常會有兩種熒光燈色溫 4000 和 5000K，目前我所接觸到的應該是5000K居多）

1.1.4          調試和驗證

具體參數的調整，應該在燈箱環境下，使用各種已知色溫的標準光源對標準色卡拍攝，在Pc機上由取色工具測量得到其與標準色板的RGB分量上的色彩偏差，相應的調整各分量增益的比例關係。爲了更精確的得到結果，曝光量增益的設置在此之前應該相對準確的校正過

顏色相關特效處理

1.1        grayscale （灰階）

灰階圖的效果就是將彩色圖片轉換爲黑白圖片。

1.2        理論

理論上，在YUV空間，將UV分量丟棄，只保留Y分量，這樣就可以得到黑白圖像，這也是彩色電式機信號能兼容黑白電視機的原理。如下圖理論上Y值一樣的顏色（右邊是用acdsee轉成灰度圖的效果），在grayscale模式下看應該是一樣的顏色。

    

算法上的操作，理論上應該把UV值改成灰色對應數值就可以了。不過根據軟件算法和硬件結構的不同，具體代碼也會有不同。

1.3        以某平臺爲例

核心的兩行代碼如下：

       SET_HUE_U_GAIN(0);

       SET_HUE_V_GAIN(0);

這裏設置UV GAIN爲0，如果UV offset設置爲128的話，最終得到的UV就是128，這就和理論是相符合的。

1.4        sepia / sepiagreen / sepiablue

所謂的復古（綠，藍）就是在灰階的基礎上，對UV值額外再做了一個offset，將灰度圖轉換成某種顏色的梯度圖。理論上爲了獲得藍色效果，應該增加藍色差信號，減小紅色差信號。即增大U，減小V。

以sepiablue效果爲例，這裏的字節的MSB表示符號位：所以88爲88，158爲-30。

    SET_HUE_U_GAIN(0); 

    SET_HUE_V_GAIN(0); 

    SET_HUE_U_OFFSET(88);

    SET_HUE_V_OFFSET(158);

 

 

1.5        negative

所謂負片效果，就是將圖像的顏色反轉，看起來就像是在看膠片底片時的效果。這從理論上也很容易理解和處理，就是在RGB空間，取其補色，具體的操作就是用255分別減去RGB得到新的RGB值。通常會在ISP中實現該功能。

 

2         小結

理解了原理，要做出其它顏色變換方面的效果就很容易了。

基本上，在顏色校正和處理方面，需要考慮的相關參數大致包括：

自動WB上下限，自動白平衡時的目標範圍，RGB gain, UV gain, UV offset, color correction.有些還會有saturation 和 hue相關的設置。

從sensor或ISP硬件處理的流程上說，通常方向是先做RGB gain，再做color correction,最後做YUV空間的處理。所以調整效果的時候，爲了減少參數之間的相互影響，基本上也可以按這個順序來調整參數。

1.1        亮度感應及曝光

1.1.1          感光寬容度

從最明亮到最黑暗，假設人眼能夠看到一定的範圍，那麼膠片（或CCD等電子感光器件）所能表現的遠比人眼看到的範圍小的多，而這個有限的範圍就是感光寬容度。

人眼的感光寬容度比膠片要高很多，而膠片的感光寬容度要比數碼相機的ccd高出很多！瞭解這個概念之後，我們就不難了解，爲什麼在逆光的條件下，人眼能看清背光的建築物以及耀眼的天空雲彩。而一旦拍攝出來，要麼就是雲彩顏色絢爛而建築物變成了黑糊糊的剪影，要麼就是建築物色彩細節清楚而原本美麗的雲彩卻成了白色的一片

再看人眼的結構，有瞳孔可以控制通光量，有桿狀感光細胞和椎狀感光細胞以適應不同的光強，可見即使人眼有着很高的感光寬容度，依然有亮度調節系統，以適應光強變化。

那麼對於camera sensor來說，正確的曝光就更爲重要了！

1.1.2          自動曝光和18%灰

對於sensor來說，又是如何來判斷曝光是否正確呢？很標準的做法就是在YUV空間計算當前圖像的Y值的均值。調節各種曝光參數設定（自動或手動），使得該均值落在一個目標值附近的時候，就認爲得到了正確的曝光。

那麼如何確定這個Y的均值，以及如何調整參數使得sensor能夠將當前圖像的亮度調整到這個範圍呢？

這就涉及到一個概念 18%灰，一般認爲室內室外的景物，在通常的情況下，其平均的反光係數大約爲18%，而色彩均值，如前所述，可以認爲是一種中灰的色調。這樣，可以通過對反光率爲18%的灰板拍攝，調整曝光參數，使其顏色接近爲中等亮度的灰色（Y值爲128）。然後，對於通常的景物，就能自動的得到正確的曝光了。

 

當然這種自動判斷曝光參數的AE功能不是萬能的，對於反光率偏離通常均值的場景，比如雪景，夜景等，用這種方法就無法得到正確的曝光量了。所以在sensor的軟件處理模塊中，通常還會提供曝光級別的設定功能，強制改變自動曝光的判斷標準。比如改變預期的亮度均值等。

1.1.3          曝光級別設定

在多數數碼相機和拍照手機上都可以看到曝光級別設定的功能，如前所述，這種設定實際上是在自動曝光的基礎上給用戶提供一定的曝光控制能力，強制改變camera sensor的曝光判斷標準，獲得用戶想要的效果。

通常的做法就是改變Y值均值的預期值，使得sensor在自動曝光時以新的Y預期值爲目標，自動調整Exptime 和 AG。

1.1.4          gamma校正

曝光的均值正確了，不代表整體圖像的亮度分佈就和人眼所看到的保持一致了。

事實上，人眼對亮度的響應並不是一個線性的比例關係，而各種涉及到光電轉換的設備的輸入輸出特性曲線一般也是非線性的，且表現爲冪函數的形式：y＝xn , 所以整個圖像系統的傳遞函數是一個冪函數。g＝ g1×g2×…×gn

對於sensor來說，其響應倒是接近爲線性關係，所以爲了在各種設備上正確輸出符合人眼對亮度的響應的圖像，就需要進行校正。

冪函數的指數的倒數就是通常所說的gamma值。

歸一化的gamma曲線

校正的函數可以表示爲 '>1，通常對於Window的輸出顯示系統，gamma值爲2.2，而對於蘋果的輸出顯示系統和打印系統來說，gamma值爲1.8。

實際上，sensor在做gamma校正的時候，通常也一併作了從raw格式的10bit的數據到8bit數據的轉換，所以這時候的公式可以表示爲           對比度

對比度的調整在一定程度上說，其實也就是對gamma曲線的調整，增大對比度就是提高Gamma值。對於圖像處理來說，也有在硬件gamma校正後，單獨由軟件再進行一次類似的冪函數變換來調整對比度。

1.1.6          曝光參數的調整

曝光強度的調整，可以通過改變曝光時間，也可以通過改變亮度增益AG來實現。

曝光時間受到楨頻的限制，比如攝像時要求15幀每秒的話，這時候曝光時間最長就不能超過1/15s，可能還有別的條件限制，實際的曝光時間還要短，在光線弱的情況下，單獨調整曝光時間就無法滿足幀頻的需要了。

這時候還可以調整增益AG，來控制曝光的增益，降低曝光時間。但是，這樣做的缺點是以犧牲圖像質量爲代價的，AG的增強，伴隨的必然是信噪比的降低，圖像噪聲的增強。

所以，以圖像質量爲優先考慮的時候，曝光參數的調節通常是優先考慮調節曝光時間，其次在考慮曝光增益。當然曝光時間也不能過長以免由於抖動造成圖像的模糊，而在拍攝運動場景時，對曝光時間的要求就更高了

1.1        抗噪處理

AG 的增大，不可避免的帶來噪點的增多，此外，如果光線較暗，曝光時間過長，也會增加噪點的數目（從數碼相機上看，主要是因爲長時間曝光，感光元件溫度升高，電流噪聲造成感光元件噪點的增多），而感光元件本身的缺陷也是噪點甚至壞點的來源之一。因此，通常sensor集成或後端的ISP都帶有降噪功能的相關設置。

1.1.1          啓動時機

根據噪點形成的原因，主要是AG或Exptime超過一定值後需要啓動降噪功能，因此通常需要確定這兩個參數的闕值，過小和過大都不好。

從下面的降噪處理的辦法將會看到，降噪勢附帶的帶來圖像質量的下降，所以過早啓動降噪功能，在不必要的情況下做降噪處理不但增加處理器或ISP的負擔，還有可能適得其反。而過遲啓動降噪功能，則在原本需要它的時候，起不到相應的作用。

1.1.2          判定原則和處理方式

那麼如何判定一個點是否是噪點呢？我們從人是如何識別噪點的開始討論，對於人眼來說，判定一個點是噪點，無外乎就是這一點的亮度或顏色與邊上大部分的點差異過大。從噪點產生的機制來說，顏色的異常應該是總是伴隨着亮度的異常，而且對亮度異常的處理工作量比顏色異常要小，所以通常sensor ISP的判定原則是一個點的亮度與周圍點的亮度的差值大於一個闕值的時候，就認爲該點是一個噪點。

處理的方式，通常是對周圍的點取均值來替代原先的值，這種做法並不增加信息量，類似於一個模糊算法。

對於高端的數碼相機，擁有較強的圖像處理芯片，在判定和處理方面是否有更復雜的算法，估計也是有可能的。比如亮度和顏色綜合作爲標準來判定噪點，採用運算量更大的插值算法做補償，對於sensor固有的壞點，噪點，採用屏蔽的方式拋棄其數據（Nikon就是這麼做的，其它廠商應該也如此）等等。

1.1.3          效果

對於手機sensor來說，這種降噪處理的作用有多大，筆者個人認爲應該很有限，畢竟相對數碼相機，手機sensor的鏡頭太小，通光量小，所以其基準AG勢必就比相機的增益要大（比如相當於普通家用數碼相機ISO800的水平），這樣才能獲得同樣的亮度，所以電流噪聲帶來的影響也就要大得多。這樣一來，即使最佳情況，噪點也會很多，數據本身的波動就很大，這也就造成我們在手機照片上勢必會看到的密密麻麻的花點，如果全部做平均，降低了噪點的同時，圖像也會變得模糊，所以手機噪點的判斷闕值會設得比較高，以免涉及面過大，模糊了整體圖像。這樣一來一是數據本身就差，二是降噪的標準也降低了，造成總體效果不佳。

1.2        數碼變焦

數碼變焦可以有兩種形式：

其一，是通過插值算法，對圖像進行插值運算，將圖像的尺寸擴大到所需的規格，這種算法就其效果而言，並不理想，尤其是當使用在手機上的時候，手機上的攝像頭本身得到的數據就有較大的噪聲，再插值的話，得到的圖像幾乎沒法使用。實際上，即使是數碼相機的數碼變焦功能也沒有太大的實用價值。如果插值算法沒有硬件支持，則需要在應用層實現。我司某平臺的數碼變焦用的就是該種辦法。

 

其二，其實是一種僞數碼變焦的形式，當攝像頭不處在最大分辨率格式的情況下，比如130萬像素的sensor使用640*480的規格拍照時，仍舊設置sersor工作在1280*960的分辨率下，而後通過採集中央部分的圖像來獲取640*480的照片，使得在手機上看來所拍物體尺寸被放大了一倍。也有很多手機採用的是這種數碼變焦方式，這種辦法幾乎不需要額外的算法支持，對圖像質量也沒有影響，缺點是隻有小尺寸情況下可以採用。此外在DV方式下也可以實現所謂的數碼變焦放大拍攝功能。（這應該是一個賣點，對Dv來說，這種數碼變焦還是有實際意義的）

要採用這種變焦模式，驅動需要支持windowing功能，獲取所需部分的sensor圖像數據。

1.3        頻閃抑制功能

1.3.1          何謂頻閃

日常使用的普通光源如白熾燈、日光燈、石英燈等都是直接用220/50Hz交流電工作，每秒鐘內正負半周各變化50次，因而導致燈光在1秒鐘內發生100（50×2）次的閃爍，再加上市電電壓的不穩定，燈光忽明忽暗，這樣就產生了所謂的“頻閃”。

下表顯示了幾種光源的光強波動情況：

因爲人眼對光強變化有一定的遲滯和適應性，所以通常看不出光源的亮度變化。但是依然還是會增加眼睛的疲勞程度。所以市場上纔會有所謂的無頻閃燈銷售。

1.3.2          對頻閃的抑制

對於camera sensor來說，沒有人眼的遲滯和適應過程，所以對光源亮度的變化是比較敏感的。如果不加抑制，在預覽和DV模式下，可能會有明顯的圖像的明亮變化閃爍的現象發生。

如何解決呢？考慮到頻閃的週期性，在一個週期內，光源亮度的累積值，應該是大體一致的，所以，如果控制曝光的時間是頻閃週期的整倍數，那麼每一幀圖像的亮度就大體是一致的了，這樣就可以有效地抑制頻閃對圖像亮度的影響。

所以，在自動曝光的模式下，sensor會根據頻閃的頻率，調整曝光時間爲其週期的整倍數。 因爲各地的交流電的頻率不同，所以有50Hz/60Hz之分。

在具體設置相關Sensor寄存器的時候，要根據電流頻率和sensor的時鐘頻率，分辨率等，計算出頻閃週期對應的時鐘週期數等。

1         前言

 

自然界的顏色千變萬化，爲了給顏色一個量化的衡量標準，就需要建立色彩空間模型來描述各種各樣的顏色，由於人對色彩的感知是一個複雜的生理和心理聯合作用的過程，所以在不同的應用領域中爲了更好更準確的滿足各自的需求，就出現了各種各樣的色彩空間模型來量化的描述顏色。我們比較常接觸到的就包括 RGB / CMYK / YIQ / YUV / HSI等等。

 

對於數字電子多媒體領域來說，我們經常接觸到的色彩空間的概念，主要是RGB , YUV這兩種（實際上，這兩種體系包含了許多種具體的顏色表達方式和模型，如sRGB, Adobe RGB, YUV422, YUV420 …）, RGB是按三基色加光系統的原理來描述顏色，而YUV則是按照 亮度，色差的原理來描述顏色。

 

       即使只是RGB YUV這兩大類色彩空間，所涉及到的知識也是十分豐富複雜的，在下自知不具備足夠的相關專業知識，所以本文主要針對工程領域的應用及算法進行討論。

 

2         YUV相關色彩空間模型

2.1        YUV 與 YIQ YcrCb

對於YUV模型，實際上很多時候，我們是把它和YIQ / YCrCb模型混爲一談的。

實際上,YUV模型用於PAL制式的電視系統，Y表示亮度，UV並非任何單詞的縮寫。

YIQ模型與YUV模型類似，用於NTSC制式的電視系統。YIQ顏色空間中的I和Q分量相當於將YUV空間中的UV分量做了一個33度的旋轉。

YCbCr顏色空間是由YUV顏色空間派生的一種顏色空間，主要用於數字電視系統中。從RGB到YCbCr的轉換中，輸入、輸出都是8位二進制格式。

三者與RGB的轉換方程如下：

RGB -> YUV

實際上也就是：

Y=0.30R+0.59G+0.11B ， U=0.493(B－Y) ， V=0.877(R－Y)

 

RGB -> YIQ

 

RGB -> YCrCb

從公式中，我們關鍵要理解的一點是，UV / CbCr信號實際上就是藍色差信號和紅色差信號，進而言之，實際上一定程度上間接的代表了藍色和紅色的強度，理解這一點對於我們理解各種顏色變換處理的過程會有很大的幫助。

我們在數字電子多媒體領域所談到的YUV格式，實際上準確的說，是以YcrCb色彩空間模型爲基礎的具有多種存儲格式的一類顏色模型的家族（包括YUV444 / YUV422 / YUV420 / YUV420P等等）。並不是傳統意義上用於PAL制模擬電視的YUV模型。這些YUV模型的區別主要在於UV數據的採樣方式和存儲方式，這裏就不詳述。

而在Camera Sensor中，最常用的YUV模型是 YUV422格式，因爲它採用4個字節描述兩個像素，能和RGB565模型比較好的兼容。有利於Camera Sensor和Camera controller的軟硬件接口設計。

 

3         YUV2RGB快速算法分析

這裏指的YUV實際是YcrCb了 8 ) YUV2RGB的轉換公式本身是很簡單的，但是牽涉到浮點運算，所以，如果要實現快速算法，算法結構本身沒什麼好研究的了，主要是採用整型運算或者查表來加快計算速度。

首先可以推導得到轉換公式爲：

       R = Y + 1.4075 *（V-128）

       G = Y – 0.3455 *（U –128） – 0.7169 *（V –128）

       B = Y + 1.779 *（U – 128）

3.1        整型算法

要用整型運算代替浮點運算，當然是要用移位的辦法了，我們可以很容易得到下列算法：

 

       u = YUVdata[UPOS] - 128;

       v = YUVdata[VPOS] - 128;

     

rdif = v + ((v * 103) >> 8);

       invgdif = ((u * 88) >> 8) +((v * 183) >> 8);

       bdif = u +( (u*198) >> 8);

 

       r = YUVdata[YPOS] + rdif;

       g = YUVdata[YPOS] - invgdif;

       b = YUVdata[YPOS] + bdif;

 

爲了防止出現溢出，還需要判錯計算的結果是否在0-255範圍內，做類似下面的判斷。

       if (r>255)

              r=255;

       if (r<0)

              r=0;

要從RGB24轉換成RGB565數據還要做移位和或運算：

       RGBdata[1] =( (r & 0xF8) | ( g >> 5) );

       RGBdata[0] =( ((g & 0x1C) << 3) | ( b >> 3) );

3.2        部分查表法

查表法首先可以想到的就是用查表替代上述整型算法中的乘法運算。

       rdif = fac_1_4075[u];

       invgdif = fac_m_0_3455[u] + fac_m_0_7169[v];

       bdif = fac_1_779[u];

這裏一共需要4個1維數組，下標從0開始到255，表格共佔用約1K的內存空間。uv可以不需要做減128的操作了。在事先計算對應的數組元素的值的時候計算在內就好了。

對於每個像素，部分查表法用查表替代了2次減法運算和4次乘法運算，4次移位運算。但是，依然需要多次加法運算和6次比較運算和可能存在的賦值操作，相對第一種方法運算速度提高並不明顯。

3.3        完全查表法

那麼是否可以由YUV直接查表得到對應的RGB值呢？乍一看似乎不太可能，以最複雜的G的運算爲例，因爲G與YUV三者都相關，所以類似 G=YUV2G[Y][U][V]這樣的算法，一個三維下標尺寸都爲256的數組就需要佔用2的24次方約16兆空間，絕對是沒法接受的。所以目前多數都是採用部分查表法。

但是，如果我們仔細分析就可以發現，對於G我們實際上完全沒有必要採用三維數組，因爲Y只與UV運算的結果相關，與UV的個體無關，所以我們可以採用二次查表的方法將G的運算簡化爲對兩個二維數組的查表操作，如下：

G = yig2g_table[ y ][ uv2ig_table[ u ][ v ] ]；

而RB本身就只和YU或YV相關，所以這樣我們一共需要4個8*8的二維表格，需要佔用4乘2的16次方共256K內存。基本可以接受。但是對於手機這樣的嵌入式運用來說，還是略有些大了。

進一步分析，我們可以看到，因爲在手機等嵌入式運用上我們最終是要把數據轉換成RGB565格式送到LCD屏上顯示的，所以，對於RGB三分量來說，我們根本不需要8bit這麼高的精度，爲了簡單和運算的統一起見，對每個分量我們其實只需要高6bit的數據就足夠了，所以我們可以進一步把表格改爲4個6*6的二維表格，這樣一共只需要佔用16K內存！在計算表格元素值的時候還可以把最終的溢出判斷也事先做完。最後的算法如下：

 

y = (YUVdata[Y1POS] >> 2);

u = (YUVdata[UPOS] >> 2);

    v = (YUVdata[VPOS] >> 2);

   

    r = yv2r_table[ y ][ v ];

    g = yig2g_table[ y ][ uv2ig_table[ u ][ v ] ];

    b = yu2b_table[ y ][ u ];

   

    RGBdata[1] =( (r & 0xF8) | ( g >> 5) );

    RGBdata[0] =( ((g & 0x1C) << 3) | ( b >> 3) );

 

這樣相對部分查表法，我們增加了3次移位運算，而進一步減少了4次加法運算和6次比較賦值操作。

在計算表格元素數值的時候，要考慮舍入和偏移等因數使得計算的中間結果滿足數組下標非負的要求，需要一定的技巧：

採用完全查表法，相對於第一種算法，最終運算速度可以有比較明顯的提高，具體性能能提高多少，要看所在平臺的CPU運算速度和內存存取速度的相對比例。內存存取速度越快，用查表法帶來的性能改善越明顯。在我的PC上測試的結果性能大約能提高35%。而在某ARM平臺上測試只提高了約15%。

3.4        進一步的思考

實際上，上述算法：

    RGBdata[1] =( (r & 0xF8) | ( g >> 5) );

       RGBdata[0] =( ((g & 0x1C) << 3) | ( b >> 3) );

中的 (r & 0xF8) 和 ( b >> 3) 等運算也完全可以在表格中事先計算出來。另外，YU / YV的取值實際上不可能覆蓋滿6*6的範圍，中間有些點是永遠取不到的無輸入，RB的運算也可以考慮用5*5的表格。這些都可能進一步提高運算的速度，減小表格的尺寸。

另外，在嵌入式運用中，如果可能儘量將表格放在高速內存如SRAM中應該比放在SDRAM中更加能發揮查表法的優勢。

4         RGB2YUV ?

目前覺得這個是沒法將3維表格的查表運算化簡爲2維表格的查表運算了。只能用部分查表法替代其中的乘法運算。

另外，多數情況下，我們需要的還是YUV2RGB的轉換，因爲從Sensor得到的數據通常我們會用YUV數據，此外JPG和MPEG實際上也是基於YUV格式編碼的，所以要顯示解碼後的數據需要的也是YUV2RGB的運算 8 ）運氣運氣。