Windows下BMP位图格式介绍
BMP图片，是Bitmap（位图）的简称，它是windows下显示图片的基本格式。在windows下任何格式的图片文件（包括视频播放）都要转化为位图才能显示出来。各种格式的图片文件也都是在位图格式的基础上采用不同的压缩算法生成的。
位图文件主要分为如下3个部分：
|
块名称 |
对应Window结构定义 |
大小(yte) |
|
位图文件头 |
BITMAPFILEHEADER |
14 |
|
位图信息头 |
BITMAPINFOHEADER |
40 |
|
RGB颜色阵列 |
BYTE* |
由图像长宽尺寸决定 |
(1)位图文件头BITMAPFILEHEADER
结构体定义如下：
typedef struct tagBITMAPFILEHEADER
｛
UINT bfType;
DWORD bfSize;
UINT bfReserved1;
UINT bfReserved2;
DWORD bfOffBits;
} BITMAPFILEHEADER;
其中：
|
bfType |
说明文件的类型，该值必需是0x4D42（十六进制ASCII码4D代表“B”，42代表“M”），也就是字符'BM'。 |
|
bfSize |
说明该位图文件的大小，用字节为单位 |
|
bfReserved1 |
保留，必须设置为0 |
|
bfReserved2 |
保留，必须设置为0 |
|
bfOffBits |
说明从文件头开始到实际的图象数据之间的字节的偏移量。这个参数是非常有用的，因为位图信息头和调色板的长度会根据不同情况而变化，所以你可以用这个偏移值迅速的从文件中读取到位数据。 |
(2)位图信息头BITMAPINFOHEADER
结构体定义如下：
typedef struct tagBITMAPINFOHEADER
{
DWORD biSize;
LONG biWidth;
LONG biHeight;
WORD biPlanes;
WORD biBitCount;
DWORD biCompression;
DWORD biSizeImage;
LONG biXPelsPerMeter;
LONG biYPelsPerMeter;
DWORD biClrUsed;
DWORD biClrImportant;
} BITMAPINFOHEADER;
其中：
|
biSize |
说明BITMAPINFOHEADER结构所需要的字数，不是字节数。 |
|
biWidth |
说明图象的宽度，以象素个数为单位。 |
|
biHeight |
说明图象的高度，以象素个数为单位。注：这个值除了用于描述图像的高度之外，它还有另一个用处，就是指明该图像是倒向的位图，还是正向的位图。如果该值是一个正数，说明图像是倒向的，如果该值是一个负数，则说明图像是正向的。大多数的BMP文件都是倒向的位图，也就是说，高度值是一个正数。 |
|
biPlanes |
为目标设备说明位面数，其值将总是被设为1。 |
|
biBitCount |
说明比特数/象素，其值为1、4、8、16、24、或32。我们平时用到的图像绝大部分是24位和32位的 |
|
biCompression |
说明图象数据压缩的类型，同样我们只讨论没有压缩的类型：BI_RGB。 |
|
biSizeImage |
说明图象的大小，以字节为单位。当用BI_RGB格式时，可设置为0。 |
|
biXPelsPerMeter |
说明水平分辨率，用象素/米表示。 |
|
biYPelsPerMeter |
说明垂直分辨率，用象素/米表示。 |
|
biClrUsed |
说明位图实际使用的彩色表中的颜色索引数（设为0的话，则说明使用所有调色板项）。 |
|
biClrImportant |
说明对图象显示有重要影响的颜色索引的数目，如果是0，表示都重要。 |
(3) RGB颜色通道
在windows下面，RGB颜色矩阵的存储格式是BGR。
对于24 位RGB位图来说，数据格式为：蓝色B值 绿色G值 红色R值。对于24位的图像来说，因为没有Alpha通道，故整个图像都不透明。
对于32位的RGB位图来说，数据格式为：蓝色B值 绿色G值 红色R值 透明通道A值。这里，Alpha通道也称为透明通道，该值是该像素点的透明属性，取值在0（全透明）------255（不透明）之间。颜色数据区记录着每个像素对应的颜色值。其记录方式随着颜色模式的不同而不同。
biBitCount=1
表示位图最多有两种颜色，缺省情况下是黑色和白色，你也可以自己定义这两种颜色。图像信息头调色板中将有两个调色板项，称为索引0和索引1。图象数据阵列中的每一位表示一个象素。如果一个位是0，显示时就使用索引0的RGB值，如果位是1，则使用索引1的RGB值。
biBitCount=4
表示位图最多有16种颜色。每个象素用4位表示，并用这4位作为彩色表的表项来查找该象素的颜色。例如，如果位图中的第一个字节为0x1F，它表示有两个象素，第一象素的颜色就在彩色表的第2表项中查找，而第二个象素的颜色就在彩色表的第16表项中查找。调色板中缺省情况下会有16个调色板项，对应于索引0到索引15。
biBitCount=8
表示位图最多有256种颜色。每个象素用8位表示，并用这8位作为彩色表的表项来查找该象素的颜色。例如，如果位图中的第一个字节为0x1F，这个象素的颜色就在彩色表的第32表项中查找。此时，缺省情况下，调色板中会有256个调色板项，对应于索引0到索引255。
biBitCount=16
表示位图最多有65536种颜色。每个色素用16位（2个字节）表示。这种格式叫作高彩色，或叫增强型16位色，或64K色。当 biCompression成员的值是BI_RGB时，它没有调色板。16位中，最低的5位表示蓝色分量，中间的5位表示绿色分量，高的5位表示红色分量，一共占用了15位，最高的一位保留，设为0。这种格式也被称作555 16位位图。当biCompression成员的值是BI_BITFIELDS，那么情况就复杂了，首先是原来调色板的位置被三个DWORD变量占据，称为红、绿、蓝掩码。分别用于描述红、绿、蓝分量在16位中所占的位置。在Windows95（或98）中，系统可接受两种格式的位域：555和565，在555格式下，红、绿、蓝的掩码分别是：0x7C00、0x03E0、0x001F，而在565格式下，它们则分别为：0xF800、0x07E0、0x001F。你在读取一个像素之后，可以分别用掩码“与”上像素值，从而提取出想要的颜色分量（当然还要再经过适当的左右移操作）。在NT系统中，则没有格式限制，只不过要求掩码之间不能有重叠。（注：这种格式的图像使用起来是比较麻烦的，不过因为它的显示效果接近于真彩，而图像数据又比真彩图像小的多，所以，它更多的被用于游戏软件）。
biBitCount=24
表示位图最多有2的24次方，大约1670万种颜色。这种位图没有调色板（bmiColors成员尺寸为0），在位数组中，每3个字节代表一个象素，分别对应于颜色R、G、B。这种格式叫做真彩色。
biBitCount=32
表示位图最多有2的32次方种颜色。这种位图的结构与16位位图结构非常类似，当biCompression成员的值是BI_RGB时，它也没有调色板。32位中有24位用于存放RGB值，顺序是：最高位—保留，红8位、绿8位、蓝8位。这种格式也被成为888 32位位图。当biCompression成员的值是BI_BITFIELDS时，原来调色板的位置将被三个DWORD变量占据，成为红、绿、蓝掩码，分别用于描述红、绿、蓝分量在32位中所占的位置。在Windows95(or 98)中，系统只接受888格式，也就是说三个掩码的值将只能是：0xFF0000、0xFF00、0xFF。而在NT系统中，你只要注意使掩码之间不产生重叠就行。（注：这种图像格式比较规整，因为它是DWORD对齐的，所以在内存中进行图像处理时可进行汇编级的代码优化（简单））。
BMP图像数据区在存储时，2色图像每点占1位（8位为1字节）；16色图像每点占4位（半字节）；256色图像每点占8位（1字节）；真彩色图像每点占24位（3字节）。所以，整个数据区的大小也会随之变化。究其规律而言，可的出如下计算公式：图像数据信息大小=（图像宽度*图像高度*记录像素的位数）/8。
然而，未压缩的图像信息区的大小。除了真彩色模式外，其余的均大于或等于数据信息的大小。这是为什么呢？原因有两个：
1.BMP文件记录一行图像是以字节为单位的。因此，就不存在一个字节中的数据位信息表示的点在不同的两行中。也就是说，设显示模式为16色，在每个字节分配两个点信息时，如果图像的宽度位奇数，那么最后一个像素点的信息将独占一个字节，这个字节的后4位将没有意义。接下来的一个字节将开始记录下一行的信息。
2.为了显示的方便，除了真彩色外，其他的每种颜色模式的行字节数要用数据“00”补齐为4的整数倍，4字节对齐。如果显示模式为16色，当图像宽为19时，存储时每行则要补充4-(19/2+1)%4=2个字节（加1是因为里面有一个像素点要独占了一字节）。如果显示模式为256色，当图像宽为19时，每行也要补充4-19%4=1个字节。
BMP图像数据区在读取时，位图数据的偏移量为sizeof(BITMAPFILEHEADER) + sizeof(BITMAPINFOHEADER)。
由于Windows在进行行扫描的时候最小的单位为4个字节，所以当图片宽 X 每个像素的字节数 ！= 4的整数倍时要在每行的后面补上缺少的字节，以0填充（一般来说当图像宽度为2的幂时不需要对齐）。位图文件里的数据在写入的时候已经进行了行对齐，也就是说加载的时候不需要再做行对齐。但是这样一来图片数据的长度就不是：宽 X 高 X 每个像素的字节数了，我们需要通过下面的方法计算正确的数据长度
//Calculate the image data size
//widthstep，每行所占的实际字节数
int iLineByteCnt = (((m_iImageWidth*m_iBitsPerPixel) + 31) >> 5) << 2;
m_iImageDataSize = iLineByteCnt * m_iImageHeight;
