算法优化:rgb向yuv的转化最优算法,快得让你吃惊(转) 每_腾讯qq空间,qq空间免费克隆,克隆qq空间,QQ头像,QQ个性签名,都在我我QQ主题站!
算法优化:rgb向yuv的转化最优算法,快得让你吃惊(转) 每_腾讯qq空间,qq空间免费克隆,克隆qq空间,QQ头像,QQ个性签名,都在我我QQ主题站!
算法优化:rgb向yuv的转化最优算法,快得让你吃惊(转) 每
.　　奋勇前进 　　学以致用---博主简介：专注语音数字信号处理方面的研究和算法在小通达平台上边的移植和优化。有关语音/音频编解码，语音增强，语音识别，语音音质客观评估，回声消弭伴唱响变 ...
.　　奋勇前进 　　学以致用---博主简介：专注语音数字信号处理方面的研究
和算法在小通达平台上边的移植和优化。有关语音/音频编解码，语音增强，语音识别，语音音质客观评估，回声消弭伴唱响变速稳定和谐变调稳定速等功能使成为
事实。熟悉ARM 各个系列的CPU，用ARMv4,ARMv5,ARMv6 and Cortex Neon
汇编优化相关算法代码，争取perforamance 最优。今朝首要Windows mobile and Android
platform上做相关speech/audio开发。(交流QQ:) 　　 　　朋友曾经给我保举了1个有关代码优化的pdf文档《让你的软件飞起来》，看完之后，感触感染颇深。为了推广其，同时也为了自己加深印象，故将其总结为word文档。底下就是其的详细内部实质意义总结，希望能于己于人都有所帮忙。 　　速度决定于于算法 　　同样的事情，方法不一样，效验也不一样。好比，汽车引擎，可让你的速度逾越马车，却没有办法逾越音速；涡轮引擎，可以轻松逾越音障，却没有办法飞出地球；如果有火箭发念头，就可以到达火星。 　　代码的运算速度决定于于以下几个方面 　　一、
算法本身的复杂度，好比MPEG比JPEG复杂，JPEG比BMP图片的编码复杂。 　　2、
CPU自身的速度和设计架构 　　三、
CPU的总线带宽 　　四、
您自己代码的写法 　　本文首要介绍如何优化您自己的code，使成为事实软件的加速。 　　先看看我的需求 　　咱们1个图象模式识另外项目，需要将RGB格局的彩色图像先转换成曲直短长图像。 　　图像转换的公式如下： 　　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]; //计较后的成果 　　熬头个优化 　　优化原则：图像是1个2D数组，我用1个一维数组来储存。编译器处理一维数组的效率要高过二维数组。 　　先写1个代码： 　　Y = 0.299 * R + 0.587 * G + 0.114 * B; 　　void calc_lum() 　　{ 　　 　　for(i = 0; i & IMGSIZE; i++) 　　{ 　　double r,g,b,y; 　　 　　r = in[i].r; 　　g = in[i].g; 　　b = in[i].b; 　　y = 0.299 * r + 0.587 * g + 0.114 * 　　yy = 　　out[i] = 　　} 　　} 　　这大概是能想患上出来的最简略的写法了，实在看不出有啥子弊端，好了，编译一下跑一跑吧。 　　熬头次试跑 　　这个代码分别用vc6.0和gcc编译，生成二个版本，分别在pc上和我的embedded system上边跑。 　　速度多少？ 　　在PC上，由于存在硬件浮点处理器，CPU频率也够高，计较速度为20秒。 　　我的embedded system，没有以上二个上风，浮点操作被编译器分解成为了整数运算，运算速度为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; 　　这个式子好像另有点复杂，可以再砍掉1个除法运算。 　　前边的算式子D可以这样写： 　　0.299=299/96 　　所以 D = (R * 1224) / 4096 　　Y=(R*+(G*+(B*467)/4096 　　再简化为： 　　Y=(R*1224+G*2404+B*467)/4096 　　这搭的/4096除法，因为它是2的N次方，所以可以用移位操作替换，往右移位12bit就是把某个数除以4096了。 　　void calc_lum() 　　{ 　　 　　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 + 　　y = y && 12; //这搭去掉了除法运算 　　out[i] = 　　} 　　} 　　这个代码编译后，又快了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()
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() {
for(i = 0; i & IMGSIZE; i++)
int r,g,b,y;
r = D[in[i].r];//查表
E[in[i].g];
b = F[in[i].b];
y = r + g +
这一次的成绩把我吓出一身冷汗，执行时间居然从30秒一下提高到了2秒！在PC上测试这段代码，眼皮还没眨一下，代码就执行完了。一下提高15倍，爽不
爽？ 　　接续优化 　　很多embedded system的32bit CPU，都至少有二个ALU，能不克不及让二个ALU都跑起来？ 　　void calc_lum() 　　{ 　　 　　for(i = 0; i & IMGSIZE; i += 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 + 　　out[i] = 　　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] = 　　} 　　} 　　二个ALU处理的数值不克不及有数值倚赖，也就是说：某个ALU的输入前提不克不及是另外ALU的输出，这样才可以并行。 　　这次成绩是1秒。 　　查看这个代码 　　int D[256],F[256],E[256]; //查表数组 　　void table_init() 　　{ 　　 　　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() 　　{ 　　 　　for(i = 0; i & IMGSIZE; i += 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 + 　　out[i] = 　　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] =
} } 将函数声明为inline，这样编译器就会将其镶嵌到母函数中，可以削减CPU挪用子函数所产生的开消。 　　这次速度：0.5秒。 　　其实，咱们还可以飞出地球的！ 　　如果加上以下办法，应该还可以更快： 　　一、
把查表的数值放置在CPU的高速数值CACHE内里； 　　2、
把函数calc_lum()用汇编语言来写 　　其实，CPU的潜力是很大的 　　一、
不要诉苦你的CPU，记住一句话：“只要功率足够，碎砖都能飞！” 　　2、
同样的需求，写法不一样，速度可以从120秒变化为0.5秒，说明CPU的潜能是很大的！看你如何去挖掘。 　　三、
我想：如果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 　　{ 　　 　　 　　 　　}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() 　　{ 　　 　　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() 　　{ 　　 　　for(i = 0; i & IMGSIZE; i += 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
+ 1 + 2 * IMGSIZE] = V_R[in[i + 1].r] - V_G[in[i + 1].g] -
V_B[in[i + 1].b]; //V
} } 按照牛人的概念，这种算法应该长短常快的了，以后可直接使用了。^_^ 　　注：《让你的软件飞起来》下载地址： 更多好文章请看： 本文来自CSDN博客，过载请标明出处：./wxzking/arc你好ve//43 39650.aspx
发表评论：
TA的最新馆藏[转]&[转]&[转]&[转]&[转]&