YUV/YIQ色彩空间的转换
1?前言
??????? 自然界的顏色千變?nèi)f化，為了給顏色一個(gè)量化的衡量標(biāo)準(zhǔn)，就需要建立色彩空間模型來描述各種各樣的顏色，由于人對色彩的感知是一個(gè)復(fù)雜的生理和心理聯(lián)合作用的過程，所以在不同的應(yīng)用領(lǐng)域中為了更好更準(zhǔn)確的滿足各自的需求，就出現(xiàn)了各種各樣的色彩空間模型來量化的描述顏色。我們比較常接觸到的就包括 RGB / CMYK / YIQ / YUV / HSI等等。
??????? 對于數(shù)字電子多媒體領(lǐng)域來說，我們經(jīng)常接觸到的色彩空間的概念，主要是RGB , YUV這兩種（實(shí)際上，這兩種體系包含了許多種具體的顏色表達(dá)方式和模型，如sRGB, Adobe RGB, YUV422, YUV420 …）, RGB是按三基色加光系統(tǒng)的原理來描述顏色，而YUV則是按照 亮度，色差的原理來描述顏色。
??????? 即使只是RGB YUV這兩大類色彩空間，所涉及到的知識也是十分豐富復(fù)雜的，自知不具備足夠的相關(guān)專業(yè)知識，所以本文主要針對工程領(lǐng)域的應(yīng)用及算法進(jìn)行討論。
2?YUV相關(guān)色彩空間模型
2.1?YUV 與 YIQ YcrCb
??????? 對于YUV模型，實(shí)際上很多時(shí)候，我們是把它和YIQ / YCrCb模型混為一談的。
??????? 實(shí)際上,YUV模型用于PAL制式的電視系統(tǒng)，Y表示亮度，UV并非任何單詞的縮寫。
??????? YIQ模型與YUV模型類似，用于NTSC制式的電視系統(tǒng)。YIQ顏色空間中的I和Q分量相當(dāng)于將YUV空間中的UV分量做了一個(gè)33度的旋轉(zhuǎn)。
??????? YCbCr顏色空間是由YUV顏色空間派生的一種顏色空間，主要用于數(shù)字電視系統(tǒng)中。從RGB到Y(jié)CbCr的轉(zhuǎn)換中，輸入、輸出都是8位二進(jìn)制格式。
??????? 三者與RGB的轉(zhuǎn)換方程如下：
??????? RGB -> YUV：
?
?????? 實(shí)際上也就是：
Y=0.30R+0.59G+0.11B ， U=0.493(B－Y) ， V=0.877(R－Y)
??????? RGB -> YIQ：
?????? RGB -> YCrCb：
??????? 從公式中，我們關(guān)鍵要理解的一點(diǎn)是，UV / CbCr信號實(shí)際上就是藍(lán)色差信號和紅色差信號，進(jìn)而言之，實(shí)際上一定程度上間接的代表了藍(lán)色和紅色的強(qiáng)度，理解這一點(diǎn)對于我們理解各種顏色變換處理的過程會有很大的幫助。
??????? 我們在數(shù)字電子多媒體領(lǐng)域所談到的YUV格式，實(shí)際上準(zhǔn)確的說，是以YcrCb色彩空間模型為基礎(chǔ)的具有多種存儲格式的一類顏色模型的家族（包括YUV444 / YUV422 / YUV420 / YUV420P等等）。并不是傳統(tǒng)意義上用于PAL制模擬電視的YUV模型。這些YUV模型的區(qū)別主要在于UV數(shù)據(jù)的采樣方式和存儲方式，這里就不詳述。
??????? 而在Camera Sensor中，最常用的YUV模型是 YUV422格式，因?yàn)樗捎?個(gè)字節(jié)描述兩個(gè)像素，能和RGB565模型比較好的兼容。有利于Camera Sensor和Camera controller的軟硬件接口設(shè)計(jì)。
3?YUV2RGB快速算法分析
??????? 這里指的YUV實(shí)際是YcrCb了，YUV2RGB的轉(zhuǎn)換公式本身是很簡單的，但是牽涉到浮點(diǎn)運(yùn)算，所以，如果要實(shí)現(xiàn)快速算法，算法結(jié)構(gòu)本身沒什么好研究的了，主要是采用整型運(yùn)算或者查表來加快計(jì)算速度。
首先可以推導(dǎo)得到轉(zhuǎn)換公式為：
??????? R = Y + 1.4075 *（V-128）
?????? ?G = Y – 0.3455 *（U –128） – 0.7169 *（V –128）
?????? ?B = Y + 1.779 *（U – 128）
3.1?整型算法
?????? 要用整型運(yùn)算代替浮點(diǎn)運(yùn)算，當(dāng)然是要用移位的辦法了，我們可以很容易得到下列算法：
??????? 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;
為了防止出現(xiàn)溢出，還需要判錯(cuò)計(jì)算的結(jié)果是否在0-255范圍內(nèi)，做類似下面的判斷。
????????if (r>255)
????????????r=255;
?????? ?if (r<0)
????????????r=0;
??????? 要從RGB24轉(zhuǎn)換成RGB565數(shù)據(jù)還要做移位和或運(yùn)算：
????????RGBdata[1] =( (r & 0xF8)? | ( g >> 5) );
?????? ?RGBdata[0] =( ((g & 0x1C) << 3) | ( b >> 3) );
3.2?部分查表法
??????? 查表法首先可以想到的就是用查表替代上述整型算法中的乘法運(yùn)算。
??????? rdif = fac_1_4075[u];
??????? invgdif = fac_m_0_3455[u] + fac_m_0_7169[v];
??????? bdif = fac_1_779[u];
??????? 這里一共需要4個(gè)1維數(shù)組，下標(biāo)從0開始到255，表格共占用約1K的內(nèi)存空間。uv可以不需要做減128的操作了。在事先計(jì)算對應(yīng)的數(shù)組元素的值的時(shí)候計(jì)算在內(nèi)就好了。
??????? 對于每個(gè)像素，部分查表法用查表替代了2次減法運(yùn)算和4次乘法運(yùn)算，4次移位運(yùn)算。但是，依然需要多次加法運(yùn)算和6次比較運(yùn)算和可能存在的賦值操作，相對第一種方法運(yùn)算速度提高并不明顯。
3.3?完全查表法
??????? 那么是否可以由YUV直接查表得到對應(yīng)的RGB值呢？乍一看似乎不太可能，以最復(fù)雜的G的運(yùn)算為例，因?yàn)镚與YUV三者都相關(guān)，所以類似 G=YUV2G[Y][U][V]這樣的算法，一個(gè)三維下標(biāo)尺寸都為256的數(shù)組就需要占用2的24次方約16兆空間，絕對是沒法接受的。所以目前多數(shù)都是采用部分查表法。
??????? 但是，如果我們仔細(xì)分析就可以發(fā)現(xiàn)，對于G我們實(shí)際上完全沒有必要采用三維數(shù)組，因?yàn)閅只與UV運(yùn)算的結(jié)果相關(guān)，與UV的個(gè)體無關(guān)，所以我們可以采用二次查表的方法將G的運(yùn)算簡化為對兩個(gè)二維數(shù)組的查表操作，如下：
??????? G = yig2g_table[ y ][ uv2ig_table[ u ][ v ] ]；
??????? 而RB本身就只和YU或YV相關(guān)，所以這樣我們一共需要4個(gè)8*8的二維表格，需要占用4乘2的16次方共256K內(nèi)存。基本可以接受。但是對于手機(jī)這樣的嵌入式運(yùn)用來說，還是略有些大了。
??????? 進(jìn)一步分析，我們可以看到，因?yàn)樵谑謾C(jī)等嵌入式運(yùn)用上我們最終是要把數(shù)據(jù)轉(zhuǎn)換成RGB565格式送到LCD屏上顯示的，所以，對于RGB三分量來說，我們根本不需要8bit這么高的精度，為了簡單和運(yùn)算的統(tǒng)一起見，對每個(gè)分量我們其實(shí)只需要高6bit的數(shù)據(jù)就足夠了，所以我們可以進(jìn)一步把表格改為4個(gè)6*6的二維表格，這樣一共只需要占用16K內(nèi)存！在計(jì)算表格元素值的時(shí)候還可以把最終的溢出判斷也事先做完。最后的算法如下：
??????? 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次移位運(yùn)算，而進(jìn)一步減少了4次加法運(yùn)算和6次比較賦值操作。
??????? 在計(jì)算表格元素?cái)?shù)值的時(shí)候，要考慮舍入和偏移等因數(shù)使得計(jì)算的中間結(jié)果滿足數(shù)組下標(biāo)非負(fù)的要求，需要一定的技巧。
??????? 采用完全查表法，相對于第一種算法，最終運(yùn)算速度可以有比較明顯的提高，具體性能能提高多少，要看所在平臺的CPU運(yùn)算速度和內(nèi)存存取速度的相對比例。內(nèi)存存取速度越快，用查表法帶來的性能改善越明顯。在我的PC上測試的結(jié)果性能大約能提高35%。而在某ARM平臺上測試只提高了約15%。
3.4?進(jìn)一步的思考
??????? 實(shí)際上，上述算法：
????????RGBdata[1] =( (r & 0xF8)? | ( g >> 5) );
??????? RGBdata[0] =( ((g & 0x1C) << 3) | ( b >> 3) );
??????? 中的 (r & 0xF8) 和 ( b >> 3) 等運(yùn)算也完全可以在表格中事先計(jì)算出來。另外，YU / YV的取值實(shí)際上不可能覆蓋滿6*6的范圍，中間有些點(diǎn)是永遠(yuǎn)取不到的無輸入，RB的運(yùn)算也可以考慮用5*5的表格。這些都可能進(jìn)一步提高運(yùn)算的速度，減小表格的尺寸。
??????? 另外，在嵌入式運(yùn)用中，如果可能盡量將表格放在高速內(nèi)存如SRAM中應(yīng)該比放在SDRAM中更加能發(fā)揮查表法的優(yōu)勢。
4?RGB2YUV ?
??????? 目前覺得這個(gè)是沒法將3維表格的查表運(yùn)算化簡為2維表格的查表運(yùn)算了。只能用部分查表法替代其中的乘法運(yùn)算。
??????? 另外，多數(shù)情況下，我們需要的還是YUV2RGB的轉(zhuǎn)換，因?yàn)閺腟ensor得到的數(shù)據(jù)通常我們會用YUV數(shù)據(jù)，此外JPG和MPEG實(shí)際上也是基于YUV格式編碼的，所以要顯示解碼后的數(shù)據(jù)需要的也是YUV2RGB的運(yùn)算。
本人評論：可用于期于顏色的圖象處理。對與人臉膚色，一般取 100>=I>=30。
總結(jié)
以上是生活随笔為你收集整理的YUV/YIQ色彩空间的转换的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
