BMP是英文Bitmap（位图）的简写，它是Windows操作系统中的标准图像文件格式，能够被多种Windows应用程序所支持。随着Windows操作系统的流行与丰富的Windows应用程序的开发，BMP位图格式理所当然地被广泛应用。这种格式的特点是包含的图像信息较丰富，几乎不进行压缩，但由此导致了它与生俱生来的缺点--占用磁盘空间过大。所以，目前BMP在单机上比较流行。
　　BMP文件格式分析
　　简介
　　BMP(Bitmap-File)图形文件是Windows采用的图形文件格式，在Windows环境下运行的所有图象处理软件都支持BMP图象文件格式。Windows系统内部各图像绘制操作都是以BMP为基础的。Windows 3.0以前的BMP图文件格式与显示设备有关，因此把这种BMP图象文件格式称为设备相关位图DDB(device-dependent bitmap)文件格式。Windows 3.0以后的BMP图象文件与显示设备无关，因此把这种BMP图象文件格式称为设备无关位图DIB(device-independent bitmap)格式（注：Windows 3.0以后，在系统中仍然存在DDB位图，象BitBlt()这种函数就是基于DDB位图的，只不过如果你想将图像以BMP格式保存到磁盘文件中时，微软极力推荐你以DIB格式保存），目的是为了让Windows能够在任何类型的显示设备上显示所存储的图象。BMP位图文件默认的文件扩展名是BMP或者bmp（有时它也会以.DIB或.RLE作扩展名）。
　　6.1.2 文件结构
　　位图文件可看成由4个部分组成：位图文件头(bitmap-file header)、位图信息头(bitmap-information header)、彩色表(color table)和定义位图的字节阵列，它具有如下所示的形式。
　　位图文件的组成
　　结构名称
　　符号
　　位图文件头(bitmap-file header) BITMAPFILEHEADER bmfh
　　位图信息头(bitmap-information header) BITMAPINFOHEADER bmih
　　彩色表(color table) RGBQUAD aColors[]
　　图象数据阵列字节 BYTE aBitmapBits[]
　　位图文件结构可综合在表6-01中。
　　表01 位图文件结构内容摘要
　　偏移量
　　域的名称
　　大小
　　内容
　　图象文件
　　头
　　0000h 文件标识 2 bytes 两字节的内容用来识别位图的类型：
　　‘BM’ ： Windows 3.1x, 95, NT, …
　　‘BA’ ：OS/2 Bitmap Array
　　‘CI’ ：OS/2 Color Icon
　　‘CP’ ：OS/2 Color Pointer
　　‘IC’ ： OS/2 Icon
　　‘PT’ ：OS/2 Pointer
　　注：因为OS/2系统并没有被普及开，所以在编程时，你只需判断第一个标识“BM”就行。
　　0002h File Size 1 dword 用字节表示的整个文件的大小
　　0006h Reserved 1 dword 保留，必须设置为0
　　000Ah Bitmap Data Offset 1 dword 从文件开始到位图数据开始之间的数据(bitmap data)之间的偏移量
　　000Eh Bitmap Header Size 1 dword 位图信息头(Bitmap Info Header)的长度，用来描述位图的颜色、压缩方法等。下面的长度表示：
　　28h - Windows 3.1x, 95, NT, …
　　0Ch - OS/2 1.x
　　F0h - OS/2 2.x
　　注：在Windows95、98、2000等操作系统中，位图信息头的长度并不一定是28h，因为微软已经制定出了新的BMP文件格式，其中的信息头结构变化比较大，长度加长。所以最好不要直接使用常数28h，而是应该从具体的文件中读取这个值。这样才能确保程序的兼容性。
　　0012h Width 1 dword 位图的宽度，以象素为单位
　　0016h Height 1 dword 位图的高度，以象素为单位
　　001Ah Planes 1 word 位图的位面数（注：该值将总是1）
　　图象
　　信息
　　头
　　001Ch Bits Per Pixel 1 word 每个象素的位数
　　1 - 单色位图（实际上可有两种颜色，缺省情况下是黑色和白色。你可以自己定义这两种颜色）
　　4 - 16 色位图
　　8 - 256 色位图
　　16 - 16bit 高彩色位图
　　24 - 24bit 真彩色位图
　　32 - 32bit 增强型真彩色位图
　　001Eh Compression 1 dword 压缩说明：
　　0 - 不压缩 (使用BI_RGB表示)
　　1 - RLE 8-使用8位RLE压缩方式(用BI_RLE8表示)
　　2 - RLE 4-使用4位RLE压缩方式(用BI_RLE4表示)
　　3 - Bitfields-位域存放方式(用BI_BITFIELDS表示)
　　0022h Bitmap Data Size 1 dword 用字节数表示的位图数据的大小。该数必须是4的倍数
　　0026h HResolution 1 dword 用象素/米表示的水平分辨率
　　002Ah VResolution 1 dword 用象素/米表示的垂直分辨率
　　002Eh Colors 1 dword 位图使用的颜色数。如8-比特/象素表示为100h或者 256.
　　0032h Important Colors 1 dword 指定重要的颜色数。当该域的值等于颜色数时（或者等于0时），表示所有颜色都一样重要
　　调色板数据 根据BMP版本的不同而不同 Palette N * 4 byte 调色板规范。对于调色板中的每个表项，这4个字节用下述方法来描述RGB的值： 1字节用于蓝色分量
　　1字节用于绿色分量
　　1字节用于红色分量
　　1字节用于填充符(设置为0)
　　图象数据 根据BMP版本及调色板尺寸的不同而不同 Bitmap Data xxx bytes 该域的大小取决于压缩方法及图像的尺寸和图像的位深度，它包含所有的位图数据字节，这些数据可能是彩色调色板的索引号，也可能是实际的RGB值，这将根据图像信息头中的位深度值来决定。
　　构件详解
　　1. 位图文件头
　　位图文件头包含有关于文件类型、文件大小、存放位置等信息，在Windows 3.0以上版本的位图文件中用BITMAPFILEHEADER结构来定义：
　　

typedef struct tagBITMAPFILEHEADER {UINT bfType;DWORD bfSize;UINT bfReserved1;UINT bfReserved2;DWORD bfOffBits;} BITMAPFILEHEADER;

　　其中：
　　bfType
　　说明文件的类型.（该值必需是0x4D42，也就是字符'BM'。我们不需要判断OS/2的位图标识，这么做现在来看似乎已经没有什么意义了，而且如果要支持OS/2的位图，程序将变得很繁琐。所以，在此只建议你检察'BM'标识）
　　bfSize
　　说明文件的大小，用字节为单位
　　bfReserved1
　　保留，必须设置为0
　　bfReserved2
　　保留，必须设置为0
　　bfOffBits
　　说明从文件头开始到实际的图象数据之间的字节的偏移量。这个参数是非常有用的，因为位图信息头和调色板的长度会根据不同情况而变化，所以你可以用这个偏移值迅速的从文件中读取到位数据。
　　2. 位图信息头
　　位图信息用BITMAPINFO结构来定义，它由位图信息头(bitmap-information header)和彩色表(color table)组成，前者用BITMAPINFOHEADER结构定义，后者用RGBQUAD结构定义。BITMAPINFO结构具有如下形式：
　　

typedef struct tagBITMAPINFO {<span style="white-space:pre">    </span>BITMAPINFOHEADER bmiHeader;<span style="white-space:pre"> </span>RGBQUAD bmiColors[1];} BITMAPINFO;

　　其中：
　　bmiHeader
　　说明BITMAPINFOHEADER结构，其中包含了有关位图的尺寸及位格式等信息
　　bmiColors
　　说明彩色表RGBQUAD结构的阵列，其中包含索引图像的真实RGB值。
　　BITMAPINFOHEADER结构包含有位图文件的大小、压缩类型和颜色格式，其结构定义为：

　typedef struct tagBITMAPINFOHEADER {<span style="white-space:pre"> </span>DWORD biSize;<span style="white-space:pre">   </span>LONG biWidth;<span style="white-space:pre">   </span>LONG biHeight;<span style="white-space:pre">  </span>WORD biPlanes;<span style="white-space:pre">  </span>WORD biBitCount;<span style="white-space:pre">    </span>DWORD biCompression;<span style="white-space:pre">    </span>DWORD biSizeImage;<span style="white-space:pre">  </span>LONG biXPelsPerMeter;<span style="white-space:pre">   </span>LONG biYPelsPerMeter;<span style="white-space:pre">   </span>DWORD biClrUsed;<span style="white-space:pre">    </span>DWORD biClrImportant;} BITMAPINFOHEADER;

　　其中：
　　biSize
　　说明BITMAPINFOHEADER结构所需要的字数。注：这个值并不一定是BITMAPINFOHEADER结构的尺寸，它也可能是sizeof(BITMAPV4HEADER)的值，或是sizeof(BITMAPV5HEADER)的值。这要根据该位图文件的格式版本来决定，不过，就现在的情况来看，绝大多数的BMP图像都是BITMAPINFOHEADER结构的（可能是后两者太新的缘故吧:-）。
　　biWidth
　　说明图象的宽度，以象素为单位
　　biHeight
　　说明图象的高度，以象素为单位。注：这个值除了用于描述图像的高度之外，它还有另一个用处，就是指明该图像是倒向的位图，还是正向的位图。如果该值是一个正数，说明图像是倒向的，如果该值是一个负数，则说明图像是正向的。大多数的BMP文件都是倒向的位图，也就是时，高度值是一个正数。（注：当高度值是一个负数时（正向图像），图像将不能被压缩（也就是说biCompression成员将不能是BI_RLE8或BI_RLE4）。
　　biPlanes
　　为目标设备说明位面数，其值将总是被设为1
　　biBitCount
　　说明比特数/象素，其值为1、4、8、16、24、或32
　　biCompression
　　说明图象数据压缩的类型。其值可以是下述值之一：
　　BI_RGB：没有压缩；
　　BI_RLE8：每个象素8比特的RLE压缩编码，压缩格式由2字节组成(重复象素计数和颜色索引)；
　　BI_RLE4：每个象素4比特的RLE压缩编码，压缩格式由2字节组成
　　BI_BITFIELDS：每个象素的比特由指定的掩码决定。
　　biSizeImage
　　说明图象的大小，以字节为单位。当用BI_RGB格式时，可设置为0
　　biXPelsPerMeter
　　说明水平分辨率，用象素/米表示
　　biYPelsPerMeter
　　说明垂直分辨率，用象素/米表示
　　biClrUsed
　　说明位图实际使用的彩色表中的颜色索引数（设为0的话，则说明使用所有调色板项）
　　biClrImportant
　　说明对图象显示有重要影响的颜色索引的数目，如果是0，表示都重要。
　　现就BITMAPINFOHEADER结构作如下说明：
　　(1) 彩色表的定位
　　应用程序可使用存储在biSize成员中的信息来查找在BITMAPINFO结构中的彩色表，如下所示：
　　pColor = ((LPSTR) pBitmapInfo + (WORD) (pBitmapInfo->bmiHeader.biSize))
　　(2) biBitCount
　　biBitCount=1 表示位图最多有两种颜色，缺省情况下是黑色和白色，你也可以自己定义这两种颜色。图像信息头装调色板中将有两个调色板项，称为索引0和索引1。图象数据阵列中的每一位表示一个象素。如果一个位是0，显示时就使用索引0的RGB值，如果位是1，则使用索引1的RGB值。
　　biBitCount=4 表示位图最多有16种颜色。每个象素用4位表示，并用这4位作为彩色表的表项来查找该象素的颜色。例如，如果位图中的第一个字节为0x1F，它表示有两个象素，第一象素的颜色就在彩色表的第2表项中查找，而第二个象素的颜色就在彩色表的第16表项中查找。此时，调色板中缺省情况下会有16个RGB项。对应于索引0到索引15。
　　biBitCount=8 表示位图最多有256种颜色。每个象素用8位表示，并用这8位作为彩色表的表项来查找该象素的颜色。例如，如果位图中的第一个字节为0x1F，这个象素的颜色就在彩色表的第32表项中查找。此时，缺省情况下，调色板中会有256个RGB项，对应于索引0到索引255。
　　biBitCount=16 表示位图最多有216种颜色。每个色素用16位（2个字节）表示。这种格式叫作高彩色，或叫增强型16位色，或64K色。它的情况比较复杂，当biCompression成员的值是BI_RGB时，它没有调色板。16位中，最低的5位表示蓝色分量，中间的5位表示绿色分量，高的5位表示红色分量，一共占用了15位，最高的一位保留，设为0。这种格式也被称作555 16位位图。如果biCompression成员的值是BI_BITFIELDS，那么情况就复杂了，首先是原来调色板的位置被三个DWORD变量占据，称为红、绿、蓝掩码。分别用于描述红、绿、蓝分量在16位中所占的位置。在Windows 95（或98）中，系统可接受两种格式的位域：555和565，在555格式下，红、绿、蓝的掩码分别是：0x7C00、0x03E0、0x001F，而在565格式下，它们则分别为：0xF800、0x07E0、0x001F。你在读取一个像素之后，可以分别用掩码“与”上像素值，从而提取出想要的颜色分量（当然还要再经过适当的左右移操作）。在NT系统中，则没有格式限制，只不过要求掩码之间不能有重叠。（注：这种格式的图像使用起来是比较麻烦的，不过因为它的显示效果接近于真彩，而图像数据又比真彩图像小的多，所以，它更多的被用于游戏软件）。
　　biBitCount=24 表示位图最多有224种颜色。这种位图没有调色板（bmiColors成员尺寸为0），在位数组中，每3个字节代表一个象素，分别对应于颜色R、G、B。
　　biBitCount=32 表示位图最多有232种颜色。这种位图的结构与16位位图结构非常类似，当biCompression成员的值是BI_RGB时，它也没有调色板，32位中有24位用于存放RGB值，顺序是：最高位—保留，红8位、绿8位、蓝8位。这种格式也被成为888 32位图。如果 biCompression成员的值是BI_BITFIELDS时，原来调色板的位置将被三个DWORD变量占据，成为红、绿、蓝掩码，分别用于描述红、绿、蓝分量在32位中所占的位置。在Windows 95(or 98)中，系统只接受888格式，也就是说三个掩码的值将只能是：0xFF0000、0xFF00、0xFF。而在NT系统中，你只要注意使掩码之间不产生重叠就行。（注：这种图像格式比较规整，因为它是DWORD对齐的，所以在内存中进行图像处理时可进行汇编级的代码优化（简单））。

bmp解码:

#pragma pack (1)
typedef struct tagBITMAPFILEHEADER
{__packed U16 bfType;__packed DU16 bfSize;__packed U16 bfReserved1;__packed U16 bfReserved2;__packed DU16 bfOffBits;
} BITMAPFILEHEADER;
#pragma pack ()
#pragma pack (1)
typedef struct tagBITMAPINFOHEADER
{__packed DU16 biSize;__packed LONG biWidth;__packed LONG biHeight;__packed U16 biPlanes;__packed U16 biBitCount;__packed DU16 biCompression;__packed DU16 biSizeImage;__packed LONG biXPelsPerMeter;__packed LONG biYPelsPerMeter;__packed DU16 biClrUsed;__packed  DU16 biClrImportant;
} BITMAPINFOHEADER;
#pragma pack ()
typedef struct tagRGBQUAD
{__packed U8 rgbBlue;__packed U8 rgbGreen;__packed U8 rgbRed;__packed U8 rgbReserved;
} RGBQUAD;
void BMPCopy(U8 *target,int source,int length)
{while (length--)*(target++) = *(volatile U8 *)source++;
}
U8 ReadBmp(int source,int target, int logoWidth, int logoHeight)
{DU16 CurPos;BITMAPFILEHEADER bf;BITMAPINFOHEADER bi;RGBQUAD quad[256];unsigned char c;DU16 lpBuf ,pos,rowBuf,row_scr,pos_scr;int width,height,left,top,bmpwidth;int numQuad = 0;int i,j, ScreenWidth, ScreenHeight;ScreenWidth=logoWidth;ScreenHeight=logoHeight;UartPrintf("Read Bmp\n\r");
#define Data(n) (*(volatile U8 *)(n))CurPos = source;BMPCopy((U8 *)&bf,CurPos,sizeof(BITMAPFILEHEADER));if (bf.bfType != 0x4d42){UartPrintf("Not a bmp file \n\r");return FALSE;}UartPrintf("bfType=%x\n\r",bf.bfType);UartPrintf("bfSize=%x\n\r",bf.bfSize);UartPrintf("bfReserved1=%x\n\r",bf.bfReserved1);UartPrintf("bfReserved2=%x\n\r",bf.bfReserved2);UartPrintf("bfOffBits=%x\n\r",bf.bfOffBits);CurPos += sizeof(BITMAPFILEHEADER);  BMPCopy((U8 *)&bi,CurPos,sizeof(BITMAPINFOHEADER));CurPos += sizeof(BITMAPINFOHEADER);if (bi.biBitCount < 16)numQuad = (1 << bi.biBitCount);UartPrintf("biSize=%x\n\r",bi.biSize);UartPrintf("biWidth=%x\n\r",bi.biWidth);UartPrintf("biHeight=%x\n\r",bi.biHeight);UartPrintf("biPlanes=%x\n\r",bi.biPlanes);UartPrintf("biBitCount=%x\n\r",bi.biBitCount);UartPrintf("biCompression=%x\n\r",bi.biCompression);UartPrintf("biSizeImage=%x\n\r",bi.biSizeImage);UartPrintf("biXPelsPerMeter=%x\n\r",bi.biXPelsPerMeter);UartPrintf("biYPelsPerMeter=%x\n\r",bi.biYPelsPerMeter);UartPrintf("biClrUsed=%x\n\r",bi.biClrUsed);UartPrintf("biClrImportant=%x\n\r",bi.biClrImportant);if (numQuad != 0){BMPCopy((U8 *)&quad,CurPos,numQuad*sizeof(RGBQUAD));           CurPos += numQuad*sizeof(RGBQUAD);     }UartPrintf("numQuad=%x,sizeof(RGBQUAD)=%x,\n\r",numQuad,sizeof(RGBQUAD));lpBuf = CurPos;if (bi.biWidth >= ScreenWidth){width = ScreenWidth;left = 0;}else{left = (ScreenWidth - bi.biWidth) / 2;width = bi.biWidth;}if (bi.biHeight >= ScreenHeight){height = ScreenHeight;top = 0;}else{top = (ScreenHeight -  bi.biHeight)/2;height = bi.biHeight;}UartPrintf("Show Bmp Width = %d Heigh = %d Count = %d Left = %d Top = %d,curPos = %x\n\r", width,height,bi.biBitCount,left,top,lpBuf);if (bi.biBitCount < 16){rowBuf = lpBuf;row_scr = (target + ((top+height) * ScreenWidth +left) * 2) ;bmpwidth = (bi.biWidth+3)/4 *4;for (i = 0;i<height  ;i++){pos = rowBuf;row_scr -=  ScreenWidth * 2;pos_scr = row_scr;for (j=0;j<width;j++){c = Data(pos);Data(pos_scr+1) = quad[c].rgbRed & (0xF8);Data(pos_scr+1) |= (quad[c].rgbGreen >> 5);Data(pos_scr+0) = quad[c].rgbBlue >> 3;Data(pos_scr+0) |= (quad[c].rgbGreen << 3)& 0xe0;pos ++;pos_scr +=2;}rowBuf +=  bmpwidth;   }}else if (bi.biBitCount == 16){rowBuf = lpBuf;row_scr = (target + ((top+height) * ScreenWidth +left) * 2) ;bmpwidth = bi.biWidth*2;for (i = 0;i<height;i++){pos = rowBuf;row_scr -=  ScreenWidth * 2;pos_scr = row_scr;for (j = 0;j<width;j++){
#if 1c = Data(pos+1);Data(pos_scr+1) = (c<<1);c = Data(pos+0);Data(pos_scr+1) |= (c>>7);c = Data(pos+0);Data(pos_scr+0) = ((c & 0xe0)<<1) ;c = Data(pos+0);Data(pos_scr+0) |= (c & 0x1f) ;
#elseData(pos_scr+1) =  Data(pos+1) ;Data(pos_scr+0) =  Data(pos+0) ;
#endifpos += 2;pos_scr += 2;}rowBuf +=  bmpwidth;         }}else if (bi.biBitCount == 24){rowBuf = lpBuf;row_scr = (target + ((top+height) * ScreenWidth +left) * 2) ;UartPrintf("target = %x row_scr = %x\n\r",target,row_scr);bmpwidth = ((bi.biWidth*3)+3)/4 *4;for (i = 0;i<height;i++){pos = rowBuf;row_scr -=  ScreenWidth * 2;pos_scr = row_scr;for (j = 0;j<width;j++){c = Data(pos+1);Data(pos_scr+1) = (Data(pos+2) & 0xF8);Data(pos_scr+1) |= (c >> 5);Data(pos_scr+0) =  (Data(pos+0) >> 3);Data(pos_scr+0) |= ((c << 3)& 0xe0);pos += 3;pos_scr += 2;       }rowBuf +=  bmpwidth;}}else if (bi.biBitCount == 32){rowBuf = lpBuf;row_scr = (target + ((top+height) * ScreenWidth +left) * 2) ;bmpwidth = bi.biWidth * 4;for (i = 0;i<height;i++){pos = rowBuf;row_scr -=  ScreenWidth * 2;pos_scr = row_scr;for (j=0;j<width;j++){c = Data(pos+1);Data(pos_scr+1) = (Data(pos+2) & 0xF8);Data(pos_scr+1) |= (c >> 5);Data(pos_scr+0) =  (Data(pos+0) >> 3);Data(pos_scr+0) |= ((c << 3)& 0xe0);pos += 4;             pos_scr += 2;}rowBuf +=  bmpwidth;}}else{UartPrintf("Bmp File Error \n\r");return FALSE;      }UartPrintf("Bmp File OK \n\r");return TRUE;
}

bmp编码:

BOOL  WriteBMPFile(TCHAR* BMPFilename, BYTE *pRGBBuf, int iBitCount)
{long RGB_SIZE = m_nWidth * m_nHeight * 3;if(iBitCount == 24){FILE *fp;DWORD count=0;BITMAPFILEHEADER bmpHeader;BITMAPINFO bmpInfo;if( (fp = _wfopen(BMPFilename, L"wb")) == NULL ){//  printf( "Can not create BMP file: %s\n", BMPFilename );return FALSE;}bmpHeader.bfType = 'MB';bmpHeader.bfSize = RGB_SIZE + sizeof(BITMAPFILEHEADER) + sizeof(BITMAPINFOHEADER);bmpHeader.bfReserved1 = 0;bmpHeader.bfReserved2 = 0;bmpHeader.bfOffBits = sizeof(BITMAPFILEHEADER) + sizeof(BITMAPINFOHEADER);bmpInfo.bmiHeader.biSize = sizeof(BITMAPINFOHEADER);bmpInfo.bmiHeader.biWidth = m_nWidth;bmpInfo.bmiHeader.biHeight = m_nHeight;bmpInfo.bmiHeader.biPlanes = 1;bmpInfo.bmiHeader.biBitCount = 24;bmpInfo.bmiHeader.biCompression = BI_RGB;bmpInfo.bmiHeader.biSizeImage = RGB_SIZE;bmpInfo.bmiHeader.biXPelsPerMeter = 0;bmpInfo.bmiHeader.biYPelsPerMeter = 0;bmpInfo.bmiHeader.biClrUsed = 0;bmpInfo.bmiHeader.biClrImportant = 0;if ((count=fwrite(&bmpHeader, 1, sizeof(BITMAPFILEHEADER), fp)) != sizeof(BITMAPFILEHEADER))//  printf( "write BMP file header failed: count=%d\n", count);if ((count=fwrite(&(bmpInfo.bmiHeader), 1, sizeof(BITMAPINFOHEADER), fp)) != sizeof(BITMAPINFOHEADER))//   printf( "Read BMP file info failed: count=%d\n", count);if ((count=fwrite(pRGBBuf, 1, RGB_SIZE, fp)) != RGB_SIZE)// printf( "write BMP file data failed: count=%d\n", count);fclose(fp);return TRUE;}elsereturn FALSE;
}