自然界的顏色千變萬化，為了給顏色乙個量化的衡量標準，就需要建立色彩空間模型來描述各種各樣的顏色，由於人對色彩的感知是乙個複雜的生理和心理聯合作用的過程，所以在不同的應用領域中為了更好更準確的滿足各自的需求，就出現了各種各樣的色彩空間模型來量化的描述顏色。我們比較常接觸到的就包括 rgb / cmyk / yiq / yuv / hsi等等。
對於數字電子多**領域來說，我們經常接觸到的色彩空間的概念，主要是rgb , yuv這兩種（實際上，這兩種體系包含了許多種具體的顏色表達方式和模型，如srgb, adobe rgb, yuv422, yuv420 …）, rgb是按三基色加光系統的原理來描述顏色，而yuv則是按照 亮度，色差的原理來描述顏色。
對於yuv模型，實際上很多時候，我們是把它和yiq / ycrcb模型混為一談的。
實際上,yuv模型用於pal制式的電視系統，y表示亮度，uv並非任何單詞的縮寫。
yiq模型與yuv模型類似，用於ntsc制式的電視系統。yiq顏色空間中的i和q分量相當於將yuv空間中的uv分量做了乙個33度的旋轉。
ycbcr顏色空間是由yuv顏色空間派生的一種顏色空間，主要用於數碼電視系統中。從rgb到ycbcr的轉換中，輸入、輸出都是8位二進位制格式。
三者與rgb的轉換方程如下：
實際上也就是：
從公式中，我們關鍵要理解的一點是，uv / cbcr訊號實際上就是藍色差訊號和紅色差訊號，進而言之，實際上一定程度上間接的代表了藍色和紅色的強度，理解這一點對於我們理解各種顏色變換處理的過程會有很大的幫助。
我們在數字電子多**領域所談到的yuv格式，實際上準確的說，是以ycrcb色彩空間模型為基礎的具有多種儲存格式的一類顏色模型的家族（包括yuv444 / yuv422 / yuv420 / yuv420p等等）。並不是傳統意義上用於pal制模擬電視的yuv模型。這些yuv模型的區別主要在於uv資料的取樣方式和儲存方式，這裡就不詳述。
而在camera sensor中，最常用的yuv模型是 yuv422格式，因為它採用4個位元組描述兩個畫素，能和rgb565模型比較好的相容。有利於camera sensor和camera controller的軟硬體介面設計。
這裡指的yuv實際是ycrcb了，yuv2rgb的轉換公式本身是很簡單的，但是牽涉到浮點運算，所以，如果要實現快速演算法，演算法結構本身沒什麼好研究的了，主要是採用整型運算或者查表來加快計算速度。
首先可以推導得到轉換公式為：
r = y + 1.4075 *（v-128）
g = y – 0.3455 *（u –128） – 0.7169 *（v –128）
b = y + 1.779 *（u – 128）
要用整型運算代替浮點運算，當然是要用移位的辦法了，我們可以很容易得到下列演算法：
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) );
查表法首先可以想到的就是用查表替代上述整型演算法中的乘法運算。
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次比較運算和可能存在的賦值操作，相對第一種方法運算速度提高並不明顯。
那麼是否可以由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%。
實際上，上述演算法：
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中更加能發揮查表法的優勢。
目前覺得這個是沒法將3維**的查表運算化簡為2維**的查表運算了。只能用部分查表法替代其中的乘法運算。
色彩空間轉換
rgb轉換為yuv void rgb2yuv double r,double g,double b,double y,double u,double v yuv轉換為rgb void yuv2rgb double y,double u,double v,double r,double g,doubl...
色彩空間轉換
rgb轉換為yuv void rgb2yuv double r,double g,double b,double y,double u,double v yuv轉換為rgb void yuv2rgb double y,double u,double v,double r,double g,doubl...
色彩空間轉換
rgb轉換為yuv void rgb2yuv double r,double g,double b,double y,double u,double v yuv轉換為rgb void yuv2rgb double y,double u,double v,double r,double g,doubl...