把RGB值转换为灰度值的公式：
Gray := Trunc(0.3 * Red + 0.59 * Green + 0.11 * Blue);//这句用的是浮点运算
在图像处理中，速度就是生命，能不用浮点运算，就最好不要用！
Gray := (30 * Red + 59 * Green + 11 * Blue) div 100;
虽然这样一改，运算次数多了一次，但在我的雷鸟1.1G上，处理速度大概能提高5%左右！而同主频下
(或略低，如Athlon 1600+相当于P4 1.6G)AMD的CPU浮点运算能力比Intel的较强，整数运算能力较弱，所以用Intel的CPU在这里更能体现出优势！
注：x div 100 和 Trunc(x/100)的效果是相同的，但查看其汇编代码可知一个用的指令是div,而另一个是fdiv(即进行浮点运算),
还要调用函数Trunc,其处理速度差距非常大，所以能用 x div 100 的时候就不要用 Trunc(x/100)。
但这还不是最快的，再看一个：
Gray := HiByte(77 * Red + 151 * Green + 28 * Blue);
即
Gray := (77 * Red + 151 * Green + 28 * Blue) shr 8;
(建议用后一种，不要调用函数)
这种方法比最原始的方法快了近3/4！
什么意思呢？用77,151,28分别除以256试试～～～
移位是什么意思呢，和10进制的进位，退位联系一下，是不是可以近似的理解为乘除2的n次方呢？当然这和真正意义的乘除法是不一样的！
比如shr(右移)，和真正的除法相比，比如shr 1，只有最后一个字位为0时(既为2的倍数)，它才等于除2！如二进制数110(6)右移1位变为11(3)，和6/2=3结果相同。
当然这和一开始的灰度化效果有了些误差！
如果允许存在更大的误差，还可以考虑另一种方法：
Gray := (Red shr 2) + (Red shr 4) + (Green shr 1) + (Green shr 4) + (Blue shr 3);
连乘法都没用，完全用移位实现，结合上面的解释，用除法来理解该表达式，其值只是约等于(0.3125 * Red + 0.5625 * Green + 0.125 * Blue)，
和一开始的加权平均值有了比较大的误差！但如果对速度有苛刻的要求的话，可以怎么用！这比上一种方法还能再快5%！
[cpp]
/**
* 程序名: Convert.cpp
* 功 能: 将24位真彩色图转换为8位灰度图片
* 测试图片test1.bmp放到工程目录下
*/
#include <iostream>
#include <fstream>
#include <windows.h>
#include <cstring>
using namespace std;
BITMAPFILEHEADER bmpFileHeader; //位图文件头
BITMAPINFOHEADER bmpInfoHeader; //位图信息头
RGBQUAD *pColorTable; //颜色表，注：24位真彩色图无颜色表
unsigned char *pBmpData; //位图数据
unsigned char *pGrayData; //灰度图像数据
/**
* 函数名: readBmp
* 参 数: fileName -- 要转换的图片名
* 功 能: 读取fileName文件信息，读取成功返回TRUE，反之，返回FALSE
*/
bool readBmp(char *fileName)
{
FILE *fp = fopen(fileName,"rb"); //以二进制读方式打开
if(NULL == fp)
{
cout<<"File is opened failure!"<<endl;
return FALSE;
}
//读取数据
fread(&bmpFileHeader,sizeof(BITMAPFILEHEADER),1,fp);
fread(&bmpInfoHeader,sizeof(BITMAPINFOHEADER),1,fp);
pBmpData = new unsigned char[bmpInfoHeader.biSizeImage]; //申请空间，大小为位图数据大小
fread(pBmpData,sizeof(unsigned char),bmpInfoHeader.biSizeImage,fp);
fclose(fp); //不要忘了关闭文件
return TRUE;
}
/**
* 函数名: convert
* 功 能: 实现24位真彩色图到灰度图的转换
*/
void convert()
{
//因为转换后多了个颜色表，所以要改变，对bmp文件结构不清楚的看笔记1
bmpFileHeader.bfOffBits += (sizeof(RGBQUAD) * 256);
//biSizeImg存储的为位图数据占用的字节数，转换为灰度图像后值发生改变，
//因为24为真彩色位图数据的一个像素用3各字节表示，灰度图像为1个字节
bmpInfoHeader.biBitCount = 8;
int lineBytes = (bmpInfoHeader.biWidth * 8 + 31) / 32 * 4;
int oldLineBytes = (bmpInfoHeader.biWidth * 24 + 31) / 32 * 4;
int oldSize = bmpInfoHeader.biSizeImage; //原图数据大小
bmpInfoHeader.biSizeImage = lineBytes * bmpInfoHeader.biHeight;
//定义灰度图像的颜色表
pColorTable = new RGBQUAD[256];
for(int i = 0; i < 256; i++ )
{
(*(pColorTable + i)).rgbBlue = i;
(*(pColorTable + i)).rgbGreen = i;
(*(pColorTable + i)).rgbRed = i;
(*(pColorTable + i)).rgbReserved = 0;
}
//将RGB转换为灰度值
int red,green,blue;
BYTE gray;
pGrayData = new unsigned char[bmpInfoHeader.biSizeImage];
memset(pGrayData,0,bmpInfoHeader.biSizeImage);
//这里要注意，Windows规定一个扫描行所占的字节数必须是
//4的倍数(即以long为单位),不足的以0填充，所以如果当前biWidth如果不是
//4的倍数时，要在后面补0直到为4的倍数
for(i = 0; i < bmpInfoHeader.biHeight; i++ )
{
//位图数据(pBmpData)中存储的实际像素数为biWidth个,而一个扫描行要lineByte个字节，
//多余出来的是上面补的0,所以要转换的要是实际的像素数,
//因为转换前后biWidth是相同的，而lineByte是不同的，也就是后面补的0不同
//如果还有疑惑，请留言提问，我会即时回复
for(int j = 0; j < bmpInfoHeader.biWidth; j++ )
{
red = *(pBmpData + i*oldLineBytes + 3*j );
green = *(pBmpData + i*oldLineBytes + 3*j + 1);
blue = *(pBmpData + i*oldLin
补充：软件开发 , Vc ,
