rgb2yuv

1.rgb2yuv422p

代码的运算速度取决于以下几个方面

1、 算法本身的复杂度,比如MPEG比JPEG复杂,JPEG比BMP图片的编码复杂。

2、 CPU自身的速度和设计架构

3、 CPU的总线带宽

4、 您自己代码的写法

将RGB格式的彩色图像先转换成YUV图像。

图像转换的公式如下:

Y = 0.299 * R + 0.587 * G + 0.114 * B;

图像尺寸640*480*24bit,RGB图像已经按照RGBRGB顺序排列的格式,放在内存里面了。

以下是输入和输出的定义:

#define XSIZE 640

#define YSIZE 480

#define IMGSIZE XSIZE * YSIZE

typedef struct RGB

{

unsigned char R;

unsigned char G;

unsigned char B;

}RGB;

struct RGB in[IMGSIZE]; //需要计算的原始数据

unsigned char out[IMGSIZE]; //计算后的结果

第一个优化

优化原则:图像是一个2D数组,我用一个一维数组来存储。编译器处理一维数组的效率要高过二维数组。

先写一个代码:

Y = 0.299 * R + 0.587 * G + 0.114 * B;

void calc_lum()

{

int i;

for(i = 0; i < IMGSIZE; i++)

{

double r,g,b,y;

unsigned char yy;

r = in[i].r;

g = in[i].g;

b = in[i].b;

y = 0.299 * r + 0.587 * g + 0.114 * b;

yy = y;

out[i] = yy;

}

}

这大概是能想得出来的最简单的写法了,实在看不出有什么毛病,好了,编译一下跑一跑吧。

第一次试跑

这个代码分别用vc6.0和gcc编译,生成2个版本,分别在pc上和我的embedded system上面跑。

速度多少?

在PC上,由于存在硬件浮点处理器,CPU频率也够高,计算速度为20秒。

我的embedded system,没有以上2个优势,浮点操作被编译器分解成了整数运算,运算速度为120秒左右。

去掉浮点运算

上面这个代码还没有跑,我已经知道会很慢了,因为这其中有大量的浮点运算。只要能不用浮点运算,一定能快很多。

Y = 0.299 * R + 0.587 * G + 0.114 * B;

这个公式怎么能用定点的整数运算替代呢?

0.299 * R可以如何化简?

Y = 0.299 * R + 0.587 * G + 0.114 * B;

Y = D + E + F;

D = 0.299 * R;

E = 0.587 * G;

F = 0.114 * B;

我们就先简化算式D吧!

RGB的取值范围都是0~255,都是整数,只是这个系数比较麻烦,不过这个系数可以表示为:0.299 = 299 / 1000;

所以 D = ( R * 299) / 1000;

Y = (R * 299 + G * 587 + B * 114) / 1000;

这一下,能快多少呢?

Embedded system上的速度为45秒;

PC上的速度为2秒;

0.299 * R可以如何化简

Y = 0.299 * R + 0.587 * G + 0.114 * B;

Y = (R * 299 + G * 587 + B * 114) / 1000;

这个式子好像还有点复杂,可以再砍掉一个除法运算。

前面的算式D可以这样写:

0.299=299/1000=1224/4096

所以 D = (R * 1224) / 4096

Y=(R*1224)/4096+(G*2404)/4096+(B*467)/4096

再简化为:

Y=(R*1224+G*2404+B*467)/4096

这里的/4096除法,因为它是2的N次方,所以可以用移位操作替代,往右移位12bit就是把某个数除以4096了。

void calc_lum()

{

int i;

for(i = 0; i < IMGSIZE; i++)

{

int r,g,b,y;

r = 1224 * in[i].r;

g = 2404 * in[i].g;

b = 467 * in[i].b;

y = r + g + b;

y = y >> 12; //这里去掉了除法运算

out[i] = y;

}

}

这个代码编译后,又快了20%。

虽然快了不少,还是太慢了一些,20秒处理一幅图像,地球人都不能接受。

仔细端详一下这个式子!

Y = 0.299 * R + 0.587 * G + 0.114 * B;

Y=D+E+F;

D=0.299*R;

E=0.587*G;

F=0.114*B;

RGB的取值有文章可做,RGB的取值永远都大于等于0,小于等于255,我们能不能将D,E,F都预先计算好呢?然后用查表算法计算呢?

我们使用3个数组分别存放DEF的256种可能的取值,然后。。。

查表数组初始化

int D[256],F[256],E[256];

void table_init()

{

int i;

for(i=0;i<256;i++)

{

D[i]=i*1224;

D[i]=D[i]>>12;

E[i]=i*2404;

E[i]=E[i]>>12;

F[i]=i*467;

F[i]=F[i]>>12;

}

}

void calc_lum()

{

int i;

for(i = 0; i < IMGSIZE; i++)

{

int r,g,b,y;

r = D[in[i].r];//查表

g = E[in[i].g];

b = F[in[i].b];

y = r + g + b;

out[i] = y;

}

}

这一次的成绩把我吓出一身冷汗,执行时间居然从30秒一下提高到了2秒!在PC上测试这段代码,眼皮还没眨一下,代码就执行完了。一下提高15倍,爽不爽?

继续优化
很多embedded system的32bit CPU,都至少有2个ALU,能不能让2个ALU都跑起来?

void calc_lum()

{

int i;

for(i = 0; i < IMGSIZE; i += 2) //一次并行处理2个数据

{

int r,g,b,y,r1,g1,b1,y1;

r = D[in[i].r];//查表 //这里给第一个ALU执行

g = E[in[i].g];

b = F[in[i].b];

y = r + g + b;

out[i] = y;

r1 = D[in[i + 1].r];//查表 //这里给第二个ALU执行

g1 = E[in[i + 1].g];

b1 = F[in[i + 1].b];

y = r1 + g1 + b1;

out[i + 1] = y;

}

}

2个ALU处理的数据不能有数据依赖,也就是说:某个ALU的输入条件不能是别的ALU的输出,这样才可以并行。

这次成绩是1秒。

查看这个代码

int D[256],F[256],E[256]; //查表数组

void table_init()

{

int i;

for(i=0;i<256;i++)

{

D[i]=i*1224;

D[i]=D[i]>>12;

E[i]=i*2404;

E[i]=E[i]>>12;

F[i]=i*467;

F[i]=F[i]>>12;

}

}

到这里,似乎已经足够快了,但是我们反复实验,发现,还有办法再快!

可以将int D[256],F[256],E[256]; //查表数组

更改为

unsigned short D[256],F[256],E[256]; //查表数组

这是因为编译器处理int类型和处理unsigned short类型的效率不一样。

再改动

inline void calc_lum()

{

int i;

for(i = 0; i < IMGSIZE; i += 2) //一次并行处理2个数据

{

int r,g,b,y,r1,g1,b1,y1;

r = D[in[i].r];//查表 //这里给第一个ALU执行

g = E[in[i].g];

b = F[in[i].b];

y = r + g + b;

out[i] = y;

r1 = D[in[i + 1].r];//查表 //这里给第二个ALU执行

g1 = E[in[i + 1].g];

b1 = F[in[i + 1].b];

y = r1 + g1 + b1;

out[i + 1] = y;

}

}

将函数声明为inline,这样编译器就会将其嵌入到母函数中,可以减少CPU调用子函数所产生的开销。

这次速度:0.5秒。

其实,我们还可以飞出地球的!

如果加上以下措施,应该还可以更快:

1、 把查表的数据放置在CPU的高速数据CACHE里面;

2、 把函数calc_lum()用汇编语言来写

其实,CPU的潜力是很大的

1、 不要抱怨你的CPU,记住一句话:“只要功率足够,砖头都能飞!”

2、 同样的需求,写法不一样,速度可以从120秒变化为0.5秒,说明CPU的潜能是很大的!看你如何去挖掘。

3、 我想:要是Microsoft的工程师都像我这样优化代码,我大概就可以用489跑windows XP了!

以上就是对《让你的软件飞起来》的摘录,下面,我将按照这位牛人的介绍,对RGB到YCbCr的转换算法做以总结。

Y = 0.299R + 0.587G + 0.114B
U = -0.147R - 0.289G + 0.436B
V = 0.615R - 0.515G - 0.100B

#deinfe SIZE 256

#define XSIZE 640

#define YSIZE 480

#define IMGSIZE XSIZE * YSIZE

typedef struct RGB

{

unsigned char r;

unsigned char g;

unsigned char b;

}RGB;

struct RGB in[IMGSIZE]; //需要计算的原始数据

unsigned char out[IMGSIZE * 3]; //计算后的结果

unsigned short Y_R[SIZE],Y_G[SIZE],Y_B[SIZE],U_R[SIZE],U_G[SIZE],U_B[SIZE],V_R[SIZE],V_G[SIZE],V_B[SIZE]; //查表数组

void table_init()

{

int i;

for(i = 0; i < SIZE; i++)

{

Y_R[i] = (i * 1224) >> 12; //Y对应的查表数组

Y_G[i] = (i * 2404) >> 12;

Y_B[i] = (i * 467) >> 12;

U_R[i] = (i * 602) >> 12; //U对应的查表数组

U_G[i] = (i * 1183) >> 12;

U_B[i] = (i * 1785) >> 12;

V_R[i] = (i * 2519) >> 12; //V对应的查表数组

V_G[i] = (i * 2109) >> 12;

V_B[i] = (i * 409) >> 12;

}

}

inline void calc_lum()

{

int i;

for(i = 0; i < IMGSIZE; i += 2) //一次并行处理2个数据

{

out[i] = Y_R[in[i].r] + Y_G[in[i].g] + Y_B[in[i].b]; //Y

out[i + IMGSIZE] = U_B[in[i].b] - U_R[in[i].r] - U_G[in[i].g]; //U

out[i + 2 * IMGSIZE] = V_R[in[i].r] - V_G[in[i].g] - V_B[in[i].b]; //V

out[i + 1] = Y_R[in[i + 1].r] + Y_G[in[i + 1].g] + Y_B[in[i + 1].b]; //Y

out[i + 1 + IMGSIZE] = U_B[in[i + 1].b] - U_R[in[i + 1].r] - U_G[in[i + 1].g]; //U

out[i + 1 + 2 * IMGSIZE] = V_R[in[i + 1].r] - V_G[in[i + 1].g] - V_B[in[i + 1].b]; //V

}

}

http://hi.baidu.com/zymill/item/b09445aa563d02796cd4558b

rgb2yuv

时间: 2024-11-09 00:33:43

rgb2yuv的相关文章

图像RGB2YUV与YUV2RGB格式互转介绍

1 YUV格式与RGB格式说明 由于不同国家的电视信号系统支持的图像格式不同,有YUV格式成像,也有RGB格式成像,因此为了保证兼容性,需要进行RGB与YUV格式的互转. 另外YUV格式具有亮度信息和色彩信息分离的特点,但大多数图像处理操作都是基于RGB格式,需要将RGB格式转为YUV格式.而当图像进行后期显示时,又需要将YUV转换为RGB域. 2 RGB格式转为YUV格式转换公式 将上述矩阵乘法展开,YUV(256 级别) 可以从8位 RGB 直接计算如下: Y = 0.299 R + 0.5

C++之旅 虚函数

1.为什么了解决什么 多态指同一个实体同时具有多种形式.它是面向对象程序设计(OOP)的一个重要特征.如果一个语言只支持类而不支持多态,只能说明它是基于对象的,而不是面向对象的.C++中的多态性具体体现在运行和编译两个方面.运行时多态是动态多态,其具体引用的对象在运行时才能确定.编译时多态是静态多态,在编译时就可以确定对象使用的形式.(静态绑定和动态绑定) 多态:同一操作作用于不同的对象,可以有不同的解释,产生不同的执行结果.在运行时,可以通过指向基类的指针,来调用实现派生类中的方法. C++中

YUY2(YUV) 与 RGB 格式图片的相互转换 以及 基于YUY2(YUV)的blending

这是一个项目里使用的,API里从pool里取出的格式都是YUY2,但是图像处理的API库中要求都是jepg格式. YUY2经常用于电视制式以及许多摄像头的输出格式.而我们在处理时经常需要将其转化为RGB进行处理,这里简单介绍下YUY2(YUV)与RGB之间相互转化的关系: http://msdn2.microsoft.com/en-us/library/ms893078.aspx YUY2(YUV) To RGB: C = Y - 16 D = U - 128 E = V - 128 R = c

图像RGB格式与YUV格式互转

1 // rgb2yuv.cpp : 定义控制台应用程序的入口点. 2 // 3 4 #include "stdafx.h" 5 6 7 #define Level 256 //直方图bin数 8 #define SIZEX 176 //image列尺寸 9 #define SIZEY 256 //image列尺寸 10 #define READ 0 11 #define WRITE 1 12 13 unsigned char image_in[SIZEY*SIZEX*3]; 14 u

ARGB32 to YUV12 利用 SDL1.2 SDL_ttf 在视频表面输出文本

提示:ARGB alpha通道的A + 原YUV表面的y0 + 要写进去的y1 = 计算出新的y2. 计算公式为 ( y1 * a + y0 * ( 255 - a ) ) / 255 void rgb2yuv(int r, int g, int b, int *y, int *u, int *v) { int y0, u0, v0; y0 = 66*r + 129*g + 25*b; u0 = -38*r + -74*g + 112*b; v0 = 112*r + -94*g + -18*b;

图解YUV420

YUV格式有两大类:planar和packed.对于planar的YUV格式,先连续存储所有像素点的Y,紧接着存储所有像素点的U,随后是所有像素点的V.对于packed的YUV格式,每个像素点的Y,U,V是连续交*存储的. YUV,分为三个分量,“Y”表示明亮度(Luminance或Luma),也就是灰度值:而“U”和“V” 表示的则是色度(Chrominance或Chroma),作用是描述影像色彩及饱和度,用于指定像素的颜色. 与我们熟知的RGB类似,YUV也是一种颜色编码方法,主要用于电视系

【转】图文详解YUV420数据格式

YUV格式有两大类:planar和packed. 对于planar的YUV格式,先连续存储所有像素点的Y,紧接着存储所有像素点的U,随后是所有像素点的V.对于packed的YUV格式,每个像素点的Y,U,V是连续交*存储的. YUV,分为三个分量,“Y”表示明亮度(Luminance或Luma),也就是灰度值:而“U”和“V” 表示的则是色度(Chrominance或Chroma),作用是描述影像色彩及饱和度,用于指定像素的颜色. 与我们熟知的RGB类似,YUV也是一种颜色编码方法,主要用于电视

论文眼中的 isp流水线

名词解释: [edr] 边缘增强处理算法一般调整YCbCr空间的Y值不会 明显影响到图像的色彩,也就不会出现色彩失衡的情况. [saturation] 饱和度增强处理的主要作用是使图像色彩更加丰富,通常是通过对颜色分量 Cb和Cr各乘上一个增益值完成彩色饱和度增强. 自动曝光控制通过调节CIS中像素单元的曝光时间和前端模拟 电路中数字可编程增益放大器的增益而使图像亮度达到用户自定义的目标亮度 值范围内 [黑电平] 即使没有光照射在感光器件上(高于一定温度),也会产生一定级别 的电流,这种电流就是

YUV422与RGB互相转换

  YUV422与RGB互相转换(经验证在IPNC与PC上都可以) 前一段时间在DM8168中进行颜色空间的转换,在网上找了些程序,自己也根据网上的改了下,由于能力问题,实在是不好意思说做了好几天才弄出来, 主要是因为YUV<—>RGB有各种各样的转换公式.在多次的实验修改后,终于找到了对的公式,共享出来,以便需要的人选择. 在监控系统中大多采用YUV的颜色空间,原因不说了,网上搜YUV转RGB各种介绍. 在TI的视频英语达芬奇系列中(这里只测试了DVR.IPNC), 采用如下公式: yCbC