一个完整的bmp图片, 有个54字节的头,由两部分组成一个14字节,一个40字节,直接可用tagBITMAPFILEHEADER和tagBITMAPINFOHEADER这两个结构体去组成;
这两个头里面有些位是固定格式的,只需要安排规定的填写就是。需要注意的是
然后才是位图数据。
但是存储方式需要注意,我就遇到了问题2. 如果一行数据不是4的整数倍,需要补齐为整数倍。
1)BMP文件记录一行图像是以字节为单位的。因此,就不存在一个字节中的数据位信息表示的点在不同的两行中。也就是说,设显示模式位16色,在每个字节分配两个点信息时,如果图像的宽度位奇数,那么最后一个像素点的信息将独占一个字节,这个字节的后4位将没有意义。接下来的一个字节将开始记录下一行的信息;
2)为了显示的方便,除了真彩色外,其他的每中颜色模式的行字节数要用数据“00”补齐为4的整数倍。如果显示模式为16色,当图像宽为19时,存储时每行则要补充4-(19/2+1)%4=2个字节(加1是因为里面有一个像素点要独占了一字节)。如果显示模式为256色,当图像宽为19时,每行也要补充4-19%4=1个字节;
2)为了显示的方便,除了真彩色外,其他的每中颜色模式的行字节数要用数据“00”补齐为4的整数倍。如果显示模式为16色,当图像宽为19时,存储时每行则要补充4-(19/2+1)%4=2个字节(加1是因为里面有一个像素点要独占了一字节)。如果显示模式为256色,当图像宽为19时,每行也要补充4-19%4=1个字节;
int LineLength, TotalLength;
LineLength = ImageWidth * BytesPerPixel; // 每 行数据长度大致为图象宽度乘以
// 每像素的字节数
while( LineLength % 4 != 0 ) // 修 正LineLength使其为4的倍数
++LineLenth;
TotalLength = LineLength * ImageHeight; // 数 据总长 = 每行长度 * 图象高度
这并不是效率最高的方法,但由于这个修正本身运算量并不大,使用频率也不高,我们就不需要再考虑更快 的方法了。
3)坐标系的问题,bmp是以左下为原点的坐标系。这点也需要注意,解决办法就是按照笛卡尔坐标系来读取,最后在存放的时候,将y坐标:(y*(-1))。
4)
RGB颜色阵列
有关RGB三色空间我想大家都很熟悉,这里我想说的是在Windows下,RGB颜色阵列存储的格式其实BGR。也就是说,对于24位的RGB位图像素数据格式是:
蓝色B值 | 绿色G值 | 红色R值 |
对于32位的RGB位图像素数据格式是:
蓝色B值 | 绿色G值 | 红色R值 | 透明通道A值 |
透明通道也称Alpha通道,该值是该像素点的透明属性,取值在0(全透明)到255(不透明)之间。对于24位的图像来说,因为没有Alpha通道,故整个图像都不透明。
意思就是,一个完整的bmp图片:tagBITMAPFILEHEADER+
tagBITMAPINFOHEADER+data (会根据不同的位图,填充不一样)
附:
typedef struct tagBITMAPFILEHEADER
{
unsigned short int bfType; //位图文件的类型,必须为BM
unsigned long bfSize; //文件大小,以字节为单位
unsigned short int bfReserverd1; //位图文件保留字,必须为0
unsigned short int bfReserverd2; //位图文件保留字,必须为0
unsigned long bfbfOffBits; //位图文件头到数据的偏移量,以字节为单位
}BITMAPFILEHEADER;
typedef struct tagBITMAPINFOHEADER
{
long biSize; //该结构大小,字节为单位
long biWidth; //图形宽度以象素为单位
long biHeight; //图形高度以象素为单位
short int biPlanes; //目标设备的级别,必须为1
short int biBitcount; //颜色深度,每个象素所需要的位数
short int biCompression; //位图的压缩类型
long biSizeImage; //位图的大小,以字节为单位
long biXPelsPermeter; //位图水平分辨率,每米像素数
long biYPelsPermeter; //位图垂直分辨率,每米像素数
long biClrUsed; //位图实际使用的颜色表中的颜色数
long biClrImportant; //位图显示过程中重要的颜色数
}BITMAPINFOHEADER;