YUV2RGB快速算法分析

        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）

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) );

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、 完全查表法

        那么是否可以由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%。

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的运算。

以下是从DirectShow中摘抄的相关文章

        计算机彩色显示器显示色彩的原理与彩色电视机一样，都是采用R（Red）、G（Green）、B（Blue）相加混色的原理：通过发射出三种不同强 度的电子束，使屏幕内侧覆盖的红、绿、蓝磷光材料发光而产生色彩。这种色彩的表示方法称为RGB色彩空间表示（它也是多媒体计算机技术中用得最多的一种色 彩空间表示方法）。

        根据三基色原理，任意一种色光F都可以用不同分量的R、G、B三色相加混合而成。

F = r [ R ] + g [ G ] + b [ B ]

        其中，r、g、b分别为三基色参与混合的系数。当三基色分量都为0（最弱）时混合为黑色光；而当三基色分量都为k（最强）时混合为白色光。调整r、g、b三个系数的值，可以混合出介于黑色光和白色光之间的各种各样的色光。

        那 么YUV又从何而来呢？在现代彩色电视系统中，通常采用三管彩色摄像机或彩色CCD摄像机进行摄像，然后把摄得的彩色图像信号经分色、分别放大校正后得到 RGB，再经过矩阵变换电路得到亮度信号Y和两个色差信号R－Y（即U）、B－Y（即V），最后发送端将亮度和色差三个信号分别进行编码，用同一信道发送 出去。这种色彩的表示方法就是所谓的YUV色彩空间表示。

       采用YUV色彩空间的重要性是它的亮度信号Y和色度信号U、V是分离的。如果只有Y信号分量而没有U、V分量，那么这样表示的图像就是黑白灰度图像。彩色电视采用YUV空间正是为了用亮度信号Y解决彩色电视机与黑白电视机的兼容问题，使黑白电视机也能接收彩色电视信号。

YUV与RGB相互转换的公式如下（RGB取值范围均为0-255）：

Y = 0.299R + 0.587G + 0.114B

U = -0.147R - 0.289G + 0.436B

V = 0.615R - 0.515G - 0.100B

R = Y + 1.14V

G = Y - 0.39U - 0.58V

B = Y + 2.03U

        在DirectShow中，常见的RGB格式有RGB1、RGB4、RGB8、RGB565、RGB555、RGB24、RGB32、ARGB32 等；常见的YUV格式有YUY2、YUYV、YVYU、UYVY、AYUV、Y41P、Y411、Y211、IF09、IYUV、YV12、YVU9、 YUV411、YUV420等。作为视频媒体类型的辅助说明类型（Subtype），它们对应的GUID见表2.3。

表2.3 常见的RGB和YUV格式

GUID    格式描述

MEDIASUBTYPE_RGB1    2色，每个像素用1位表示，需要调色板

MEDIASUBTYPE_RGB4    16色，每个像素用4位表示，需要调色板

MEDIASUBTYPE_RGB8    256色，每个像素用8位表示，需要调色板

MEDIASUBTYPE_RGB565    每个像素用16位表示，RGB分量分别使用5位、6位、5位

MEDIASUBTYPE_RGB555    每个像素用16位表示，RGB分量都使用5位（剩下的1位不用）

MEDIASUBTYPE_RGB24    每个像素用24位表示，RGB分量各使用8位

MEDIASUBTYPE_RGB32    每个像素用32位表示，RGB分量各使用8位（剩下的8位不用）

MEDIASUBTYPE_ARGB32    每个像素用32位表示，RGB分量各使用8位（剩下的8位用于表示Alpha通道值）

MEDIASUBTYPE_YUY2    YUY2格式，以4:2:2方式打包

MEDIASUBTYPE_YUYV    YUYV格式（实际格式与YUY2相同）

MEDIASUBTYPE_YVYU    YVYU格式，以4:2:2方式打包

MEDIASUBTYPE_UYVY    UYVY格式，以4:2:2方式打包

MEDIASUBTYPE_AYUV    带Alpha通道的4:4:4 YUV格式

MEDIASUBTYPE_Y41P    Y41P格式，以4:1:1方式打包

MEDIASUBTYPE_Y411    Y411格式（实际格式与Y41P相同）

MEDIASUBTYPE_Y211    Y211格式

MEDIASUBTYPE_IF09    IF09格式

MEDIASUBTYPE_IYUV    IYUV格式

MEDIASUBTYPE_YV12    YV12格式

MEDIASUBTYPE_YVU9    YVU9格式

下面分别介绍各种RGB格式。

        RGB1、RGB4、RGB8都是调色板类型的RGB格式，在描述这些媒体类型的格式细节时，通常会在BITMAPINFOHEADER数据结构后面跟着 一个调色板（定义一系列颜色）。它们的图像数据并不是真正的颜色值，而是当前像素颜色值在调色板中的索引。以RGB1（2色位图）为例，比如它的调色板中 定义的两种颜色值依次为0x000000（黑色）和0xFFFFFF（白色），那么图像数据001101010111…（每个像素用1位表示）表示对应各 像素的颜色为：黑黑白白黑白黑白黑白白白…。

        RGB565使用16位表示一个像素，这16位中的5位用于R，6位用于G，5位用于B。程序中通常使用一个字（WORD，一个字等于两个字节）来操作一个像素。当读出一个像素后，这个字的各个位意义如下：

高字节              低字节

R R R R R G G G     G G G B B B B B

可以组合使用屏蔽字和移位操作来得到RGB各分量的值：

#define RGB565_MASK_RED    0xF800

#define RGB565_MASK_GREEN  0x07E0

#define RGB565_MASK_BLUE   0x001F

R = (wPixel & RGB565_MASK_RED) >> 11;   // 取值范围0-31

G = (wPixel & RGB565_MASK_GREEN) >> 5;  // 取值范围0-63

B =  wPixel & RGB565_MASK_BLUE;         // 取值范围0-31

        RGB555是另一种16位的RGB格式，RGB分量都用5位表示（剩下的1位不用）。使用一个字读出一个像素后，这个字的各个位意义如下：

高字节             低字节

X R R R R G G       G G G B B B B B       （X表示不用，可以忽略）

可以组合使用屏蔽字和移位操作来得到RGB各分量的值：

#define RGB555_MASK_RED    0x7C00

#define RGB555_MASK_GREEN  0x03E0

#define RGB555_MASK_BLUE   0x001F

R = (wPixel & RGB555_MASK_RED) >> 10;   // 取值范围0-31

G = (wPixel & RGB555_MASK_GREEN) >> 5;  // 取值范围0-31

B =  wPixel & RGB555_MASK_BLUE;         // 取值范围0-31

       RGB24使用24位来表示一个像素，RGB分量都用8位表示，取值范围为0-255。注意在内存中RGB各分量的排列顺序为：BGR BGR BGR…。通常可以使用RGBTRIPLE数据结构来操作一个像素，它的定义为：

typedef struct tagRGBTRIPLE {

BYTE rgbtBlue;    // 蓝色分量

BYTE rgbtGreen;   // 绿色分量

BYTE rgbtRed;     // 红色分量

} RGBTRIPLE;

       RGB32使用32位来表示一个像素，RGB分量各用去8位，剩下的8位用作Alpha通道或者不用。（ARGB32就是带Alpha通道的 RGB32。）注意在内存中RGB各分量的排列顺序为：BGRA BGRA BGRA…。通常可以使用RGBQUAD数据结构来操作一个像素，它的定义为：

typedef struct tagRGBQUAD {

BYTE    rgbBlue;      // 蓝色分量

BYTE    rgbGreen;     // 绿色分量

BYTE    rgbRed;       // 红色分量

BYTE    rgbReserved;  // 保留字节（用作Alpha通道或忽略）

} RGBQUAD;

       下面介绍各种YUV格式。YUV格式通常有两大类：打包（packed）格式和平面（planar）格式。前者将YUV分量存放在同一个数组中，通 常是几个相邻的像素组成一个宏像素（macro-pixel）；而后者使用三个数组分开存放YUV三个分量，就像是一个三维平面一样。表2.3中的 YUY2到Y211都是打包格式，而IF09到YVU9都是平面格式。（注意：在介绍各种具体格式时，YUV各分量都会带有下标，如Y0、U0、V0表示 第一个像素的YUV分量，Y1、U1、V1表示第二个像素的YUV分量，以此类推。）

       YUY2（和YUYV）格式为每个像素保留Y分量，而UV分量在水平方向上每两个像素采样一次。一个宏像素为4个字节，实际表示2个像素。（4:2:2的意思为一个宏像素中有4个Y分量、2个U分量和2个V分量。）图像数据中YUV分量排列顺序如下：

Y0 U0 Y1 V0    Y2 U2 Y3 V2 …

       YVYU格式跟YUY2类似，只是图像数据中YUV分量的排列顺序有所不同：

Y0 V0 Y1 U0    Y2 V2 Y3 U2 …

       UYVY格式跟YUY2类似，只是图像数据中YUV分量的排列顺序有所不同：

U0 Y0 V0 Y1    U2 Y2 V2 Y3 …

       AYUV格式带有一个Alpha通道，并且为每个像素都提取YUV分量，图像数据格式如下：

A0 Y0 U0 V0    A1 Y1 U1 V1 …

      Y41P（和Y411）格式为每个像素保留Y分量，而UV分量在水平方向上每4个像素采样一次。一个宏像素为12个字节，实际表示8个像素。图像数据中YUV分量排列顺序如下：

U0 Y0 V0 Y1    U4 Y2 V4 Y3    Y4 Y5 Y6 Y8 …

       Y211格式在水平方向上Y分量每2个像素采样一次，而UV分量每4个像素采样一次。一个宏像素为4个字节，实际表示4个像素。图像数据中YUV分量排列顺序如下：

Y0 U0 Y2 V0    Y4 U4 Y6 V4 …

        YVU9格式为每个像素都提取Y分量，而在UV分量的提取时，首先将图像分成若干个4 x 4的宏块，然后每个宏块提取一个U分量和一个V分量。图像数据存储时，首先是整幅图像的Y分量数组，然后就跟着U分量数组，以及V分量数组。IF09格式与YVU9类似。

        IYUV格式为每个像素都提取Y分量，而在UV分量的提取时，首先将图像分成若干个2 x 2的宏块，然后每个宏块提取一个U分量和一个V分量。YV12格式与IYUV类似。

        YUV411、YUV420格式多见于DV数据中，前者用于NTSC制，后者用于PAL制。YUV411为每个像素都提取Y分量，而UV分量在水平方向上 每4个像素采样一次。YUV420并非V分量采样为0，而是跟YUV411相比，在水平方向上提高一倍色差采样频率，在垂直方向上以U/V间隔的方式减小 一半色差采样，如图2.12所示。

YV12转化为RGB原理

        YV12 或者 I420的YUV颜色空间格式转换成ＲＧＢ颜色空间格式，因为一个ＹＶ１２像素大小为1.5Byte，一个RGB像素大小为3Byte。所以8个Y+2个U+2个V能转换成8个RGB像素点。