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 ）運氣運氣。

本文來自CSDN博客，轉載請標明出處：http://blog.csdn.net/ALENTAM/archive/2008/03/13/2178020.aspx