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作扩展名）。 文件结构

位图文件可看成由4个部分组成：位图文件头(bitmap-file header)、位图信息头

(bitmap-information header)、彩色表(color table)和定义位图的字节阵列，它具有如下所示的形式。

位图文件的组成 位图文件头(bitmap-file header) 位图信息头(bitmap-information header) 彩色表(color table) 图象数据阵列字节 位图文件结构可综合在表6-01中。

结构名称 符号 BITMAPFILEHEADER bmfh BITMAPINFOHEADER bmih RGBQUAD BYTE aColors[] aBitmapBits[] 表01 位图文件结构内容摘要

偏移量 域的名称 大小 2 内容 两字节的内容用来识别位图的类型： 0000h 文件标识 图象文件 头 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 1 保留，必须设置为0 dword 从文件开始到位图数据开始之间的数1 dword 据(bitmap data)之间的偏移量 位图信息头(Bitmap Info Header)的长度，用来描述位图的颜色、压缩方法等。下面的长度表示： 28h - Windows 3.1x, 95, NT, … 0Ch - OS/2 1.x F0h - OS/2 2.x 0006h Reserved 000Ah Bitmap Data Offset 000Eh Bitmap Header Size 1 注：在Windows95、98、2000等操dword 作系统中，位图信息头的长度并不一定是28h，因为微软已经制定出了新的BMP文件格式，其中的信息头结构变化比较大，长度加长。所以最好不要直接使用常数28h，而是应该从具体的文件中读取这个值。这样才能确保程序的兼容性。 0012h Width 1 位图的宽度，以象素为单位 dword 1 位图的高度，以象素为单位 dword 1 word 位图的位面数（注：该值将总是1） 每个象素的位数 0016h Height 001Ah Planes 图象 信息 001Ch Bits Per Pixel 头 1 - 单色位图（实际上可有两种颜色，缺省情况下是黑色和白色。你可以自己定义这两种颜色） 1 word 4 - 16 色位图 8 - 256 色位图 16 - 16bit 高彩色位图 24 - 24bit 真彩色位图 32 - 32bit 增强型真彩色位图 压缩说明： 0 - 不压缩 (使用BI_RGB表示) 1 - RLE 8-使用8位RLE压缩方式(用BI_RLE8表示) 001Eh Compression 1 dword 2 - RLE 4-使用4位RLE压缩方式(用BI_RLE4表示) 3 - Bitfields-位域存放方式(用BI_BITFIELDS表示) 0022h Bitmap Data Size 用字节数表示的位图数据的大小。该数1 dword 必须是4的倍数 1 用象素/米表示的水平分辨率 dword 1 用象素/米表示的垂直分辨率 0026h HResolution 002Ah VResolution dword 002Eh Colors 位图使用的颜色数。如8-比特/象素表1 dword 示为100h或者 256. 1 色数时（或者等于0时），表示所有颜dword 色都一样重要 调色板规范。对于调色板中的每个表指定重要的颜色数。当该域的值等于颜Important 0032h Colors 调色板数根据BMP版本的不同而Palette N * 4 byte 项，这4个字节用下述方法来描述RGB的值： 1 字节用于蓝色分量 1 字节用于绿色分量 1 字节用于红色分量 1 字节用于填充符(设置为0) 据 不同 根据图象数BMP版本及调色板Bitmap Data 尺寸的据 不同而不同 构件详解 1. 位图文件头 xxx bytes 该域的大小取决于压缩方法及图像的尺寸和图像的位深度，它包含所有的位图数据字节，这些数据可能是彩色调色板的索引号，也可能是实际的RGB值，这将根据图像信息头中的位深度值来决定。 位图文件头包含有关于文件类型、文件大小、存放位置等信息，在Windows 3.0以上版本的位图文件中用BITMAPFILEHEADER结构来定义： typedef struct tagBITMAPFILEHEADER { /* bmfh */ UINT bfType; DWORD bfSize; UINT bfReserved1; UINT bfReserved2; DWORD bfOffBits;

} BITMAPFILEHEADER;

其中：

?

说明文件的类型.（该值必需是0x4D42，也就是字符'BM'。我们不需要判bfType

断OS/2的位图标识，这么做现在来看似乎已经没有什么意义了，而且如果要支持OS/2的位图，程序将变得很繁琐。所以，在此只建议你检察'BM'标识）?

bfSize bfReserved1 bfReserved2

说明文件的大小，用字节为单位 保留，必须设置为0 保留，必须设置为0

说明从文件头开始到实际的图象数据之间的字节的偏移量。这个参数是非bfOffBits 常有用的，因为位图信息头和调色板的长度会根据不同情况而变化，所以你可以用这个偏移值迅速的从文件中读取到位数据。

2. 位图信息头

位图信息用BITMAPINFO结构来定义，它由位图信息头

(bitmap-information header)和彩色表(color table)组成，前者用BITMAPINFOHEADER结构定义，后者用RGBQUAD结构定义。BITMAPINFO结构具有如下形式：

typedef struct tagBITMAPINFO { /* bmi */ BITMAPINFOHEADER bmiHeader; RGBQUAD bmiColors[1]; } BITMAPINFO;

其中：

?

bmiHeader

说明BITMAPINFOHEADER结构，其中包含了有关位图的尺寸及位格式等信息

bmiColors

说明彩色表RGBQUAD结构的阵列，其中包含索引图像的真实RGB值。

BITMAPINFOHEADER结构包含有位图文件的大小、压缩类型和颜色格式，其结构定义为：

typedef struct tagBITMAPINFOHEADER { /* bmih */ DWORD biSize; LONG biWidth; LONG biHeight; WORD biPlanes; WORD biBitCount; DWORD biCompression; DWORD biSizeImage; LONG biXPelsPerMeter; LONG biYPelsPerMeter; DWORD biClrUsed;

DWORD biClrImportant; } BITMAPINFOHEADER;

其中：

?

说明BITMAPINFOHEADER结构所需要的字数。注：这个值并不一定是BITMAPINFOHEADER结构的尺寸，它也可能是biSize

sizeof(BITMAPV4HEADER)的值，或是sizeof(BITMAPV5HEADER)

的值。这要根据该位图文件的格式版本来决定，不过，就现在的情况来看，绝大多数的BMP图像都是BITMAPINFOHEADER结构的（可能是后两者太新的缘故吧:-）。

biWidth

说明图象的宽度，以象素为单位

说明图象的高度，以象素为单位。注：这个值除了用于描述图像的高度之外，它还有另一个用处，就是指明该图像是倒向的位图，还是正向的位图。如果该值是一个正数，说明图像是倒向的，如果该值是一个负数，biHeight 则说明图像是正向的。大多数的BMP文件都是倒向的位图，也就是时，高度值是一个正数。（注：当高度值是一个负数时（正向图像），图像将不能被压缩（也就是说biCompression成员将不能是BI_RLE8或BI_RLE4）。

biPlanes biBitCount

为目标设备说明位面数，其值将总是被设为1 说明比特数/象素，其值为1、4、8、16、24、或32

说明图象数据压缩的类型。其值可以是下述值之一：

BI_RGB：没有压缩；

BI_RLE8：每个象素8比特的RLE压缩编码，压缩格式由2

字节组成(重复象素计数和颜色索引)；

BI_RLE4：每个象素4比特的RLE压缩编码，压缩格式由2

字节组成

BI_BITFIELDS：每个象素的比特由指定的掩码决定。

biCompression

biSizeImage biXPelsPerMeter biYPelsPerMeter biClrUsed biClrImportant

说明图象的大小，以字节为单位。当用BI_RGB格式时，可设置为0

说明水平分辨率，用象素/米表示 说明垂直分辨率，用象素/米表示

说明位图实际使用的彩色表中的颜色索引数（设为0的话，则说明使用所有调色板项）

说明对图象显示有重要影响的颜色索引的数目，如果是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对齐的，所以在内存中进行图像处理时可进行汇编级的代码优化（简单））。 (3) ClrUsed

BITMAPINFOHEADER结构中的成员ClrUsed指定实际使用的颜色数目。如果ClrUsed设置成0，位图使用的颜色数目就等于biBitCount成员中的数目。请注意，如果ClrUsed的值不是可用颜色的最大值或不是0，则在编程时应该注意调色板尺寸的计算，比如在4位位图中，调色板的缺省尺寸应该是16＊sizeof(RGBQUAD)，但是，如果ClrUsed的值不是16或者不是0，那么调色板的尺寸就应该是ClrUsed＊sizeof(RGBQUAD)。 (4) 图象数据压缩

① BI_RLE8：每个象素为8比特的RLE压缩编码，可使用编码方式和绝对方式中的任何一种进行压缩，这两种方式可在同一幅图中的任何地方使用。 编码方式：由2个字节组成，第一个字节指定使用相同颜色的象素数目，第二个字节指定使用的颜色索引。此外，这个字节对中的第一个字节可设置为0，联合使用第二个字节的值表示：

第二个字节的值为0：行的结束。

第二个字节的值为1：图象结束。

第二个字节的值为2：其后的两个字节表示下一个象素从当前开始的水平和垂直位置

的偏移量。

绝对方式：第一个字节设置为0，而第二个字节设置为0x03～0xFF之间的一个值。在这种方式中，第二个字节表示跟在这个字节后面的字节数，每个字节包含单个象素的颜色索引。压缩数据格式需要字边界(word boundary)对齐。下面的例子是用16进制表示的8-位压缩图象数据：

03 04 05 06 00 03 45 56 67 00 02 78 00 02 05 01 02 78 00 00 09 1E 00 01

这些压缩数据可解释为 ：

压缩数据? 03 04 05 06 00 03 45 56 67 扩展数据 04 04 04? 06 06 06 06 06? 45 56 67? 00 02 78 00 02 05 01 02 78 00 00 09 1E 00 01 ② BI_RLE4：

78 78? 从当前位置右移5个位置后向下移一行 78 78? 行结束 1E 1E 1E 1E 1E 1E 1E 1E 1E? RLE编码图象结束? 编码方式：由2个字节组成，第一个字节指定象素数目，第二个字节包含两种颜色索引，一个在高4位，另一个在低4位。第一个象素使用高4位的颜色索引，第二个使用低4位的颜色索引，第3个使用高4位的颜色索引，依此类推。 绝对方式：这个字节对中的第一个字节设置为0，第二个字节包含有颜色索引数，其后续字节包含有颜色索引，颜色索引存放在该字节的高、低4位中，一个颜色索引对应一个象素。此外，BI_RLE4也同样联合使用第二个字节中的值表示：

第二个字节的值为0：行的结束。

第二个字节的值为1：图象结束。

第二个字节的值为2：其后的两个字节表示下一个象素从当前开始的水平和垂直位置

的偏移量。

下面的例子是用16进制数表示的4-位压缩图象数据：

03 04 05 06 00 06 45 56 67 00 04 78 00 02 05 01 04 78 00 00 09 1E 00 01

这些压缩数据可解释为 ：

压缩数据 03 04 05 06 扩展数据 0 4 0 0 6 0 6 0? 00 06 45 56 67 4 5 5 6 6 7? 00 04 78 7 8 7 8? 00 02 05 01 04 78 00 00 09 1E 00 01 3. 彩色表

从当前位置右移5个位置后向下移一行 7 8 7 8? 行结束 1 E 1 E 1 E 1 E 1? RLE图象结束? 彩色表包含的元素与位图所具有的颜色数相同，象素的颜色用RGBQUAD结构来定义。对于24-位真彩色图象就不使用彩色表（同样也包括16位、和32位位图），因为位图中的RGB值就代表了每个象素的颜色。彩色表中的颜色按颜色的重要性排序，这可以辅助显示驱动程序为不能显示足够多颜色数的显示设备显示彩色图象。RGBQUAD结构描述由R、G、B相对强度组成的颜色，定义如下：

typedef struct tagRGBQUAD { /* rgbq */ BYTE rgbBlue; BYTE rgbGreen; BYTE rgbRed;

BYTE rgbReserved; } RGBQUAD;

其中：

? rgbBlue rgbGreen rgbRed rgbReserved

指定蓝色强度 指定绿色强度 指定红色强度 保留，设置为0

4. 位图数据

紧跟在彩色表之后的是图象数据字节阵列。图象的每一扫描行由表示图象象素的连续的字节组成，每一行的字节数取决于图象的颜色数目和用象素表示的图象宽度。扫描行是由底向上存储的，这就是说，阵列中的第一个字节表示位图左下角的象素，而最后一个字节表示位图右上角的象素。（只针对与倒向DIB，如果

是正向DIB，则扫描行是由顶向下存储的），倒向DIB的原点在图像的左下角，而正向DIB的原点在图像的左上角。同时，每一扫描行的字节数必需是4的整倍数，也就是DWORD对齐的。如果你想确保图像的扫描行DWORD对齐，可使用下面的代码：

(((width*biBitCount)+31)>>5)<<2

每个象素为4比特的RLE压缩编码，同样也可使用编码方式和绝对方式中的任何一种进行压缩，这两种方式也可在同一幅图中的任何地方使用。这两种方式是：

BMP文件格式

一.位图结构如下：

---- 一、BMP文件结构

---- 1. BMP文件组成

---- BMP文件由文件头、位图信息头、颜色信息和图形数据四部分组成。

---- 2. BMP文件头

---- BMP文件头数据结构含有BMP文件的类型、文件大小和位图起始位置等信息。

---- 其结构定义如下:

typedef struct tagBITMAPFILEHEADER {

WORDbfType; // 位图文件的类型，必须为BM

DWORD bfSize; // 位图文件的大小，以字节为单位 WORDbfReserved1; // 位图文件保留字，必须为0 WORDbfReserved2; // 位图文件保留字，必须为0

DWORD bfOffBits; // 位图数据的起始位置，以相对于位图 // 文件头的偏移量表示，以字节为单位 } BITMAPFILEHEADER;

---- 3. 位图信息头

BMP位图信息头数据用于说明位图的尺寸等信息。

typedef struct tagBITMAPINFOHEADER{ DWORD biSize; // 本结构所占用字节数 LONGbiWidth; // 位图的宽度，以像素为单位 LONGbiHeight; // 位图的高度，以像素为单位 WORD biPlanes; // 目标设备的级别，必须为1

WORD biBitCount// 每个像素所需的位数，必须是1(双色), // 4(16色)，8(256色)或24(真彩色)之一

DWORD biCompression; // 位图压缩类型，必须是 0(不压缩), // 1(BI_RLE8压缩类型)或2(BI_RLE4压缩类型)之一 DWORD biSizeImage; // 位图的大小，以字节为单位 LONGbiXPelsPerMeter; // 位图水平分辨率，每米像素数 LONGbiYPelsPerMeter; // 位图垂直分辨率，每米像素数 DWORD biClrUsed;// 位图实际使用的颜色表中的颜色数 DWORD biClrImportant;// 位图显示过程中重要的颜色数 } BITMAPINFOHEADER;

---- 4. 颜色表

颜色表用于说明位图中的颜色，它有若干个表项，每一个表项是一个RGBQUAD类型的结构，定义一种颜色。RGBQUAD结构的定义如下:

typedef struct tagRGBQUAD {

BYTErgbBlue;// 蓝色的亮度(值范围为0-255)

BYTErgbGreen; // 绿色的亮度(值范围为0-255) BYTErgbRed; // 红色的亮度(值范围为0-255) BYTErgbReserved;// 保留，必须为0

} RGBQUAD;

颜色表中RGBQUAD结构数据的个数有biBitCount来确定: 当biBitCount=1,4,8时，分别有2,16,256个表项; 当biBitCount=24时，没有颜色表项。

位图信息头和颜色表组成位图信息，BITMAPINFO结构定义如下:

typedef struct tagBITMAPINFO {

BITMAPINFOHEADER bmiHeader; // 位图信息头 RGBQUAD bmiColors[1]; // 颜色表 } BITMAPINFO;

---- 5. 位图数据

位图数据记录了位图的每一个像素值，记录顺序是在扫描行内是从左到右,扫描行之间是从下到上。位图的一个像素值所占的字节数:

当biBitCount=1时，8个像素占1个字节; 当biBitCount=4时，2个像素占1个字节; 当biBitCount=8时，1个像素占1个字节; 当biBitCount=24时,1个像素占3个字节;

Windows规定一个扫描行所占的字节数必须是 4的倍数(即以long为单位),不足的以0填充，一个扫描行所占的字节数计算方法: DataSizePerLine= (biWidth* biBitCount+31)/8; 一个扫描行所占的字节数 DataSizePerLine= DataSizePerLine/4*4; // 字节数必须是4的倍数位图数据的大小(不压缩情况下): DataSize= DataSizePerLine* biHeight;

位图格式、编码与显象原理

Windows已经把位图技术深入运用在系统的各个方面。比如在Windows中，你在记事本， 写子板里打出来的字实际上是利用位画原理\"画\"出来的。许多Windows可执行程序有美丽 的图标，其实它是将位图技术嵌入可执行文件EXE中。图标也是利用位图原理构造的，微 软的最新的操作系统WindowsXP对位图的运用更是精妙绝伦... ...好了我们现在先放下 位图原理运用方面多姿多彩的变化，来研究下最基本的Windows画笔产生的画图编码以及 画图产生的原理。以下分析都是针对Windows画笔画产生的24位真彩色位图格式。

下面我们将解析一幅位图的十六进制代码来介绍位图的格式。在Windows画笔中创建一幅 24位真彩色的位图，将其高设为10象素，宽为5象素小位图，用红色填充，然后将其保存 到磁盘上。最后用16进制编程器打开，可以看到以下位图的十六进制格式： Offset 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

00000000 42 4D D6 00 00 00 00 00 00 00 36 00 00 00 28 00 BM?......6...(. 00000016 00 00 0A 00 00 00 05 00 00 00 01 00 18 00 00 00 ................ 00000032 00 00 A0 00 00 00 C4 0E 00 00 C4 0E 00 00 00 00 ..?..?..?.... 00000048 00 00 00 00 00 00 00 00 FF 00 00 FF 00 00 FF 00 ........?..?..?. 00000064 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 ?..?..?..?..?.. 00000080 FF 00 00 FF 00 00 00 00 FF 00 00 FF 00 00 FF 00 ..?....?..?..?. 00000096 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 ?..?..?..?..?.. 00000112 FF 00 00 FF 00 00 00 00 FF 00 00 FF 00 00 FF 00 ..?....?..?..?. 00000128 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 ?..?..?..?..?.. 00000144 FF 00 00 FF 00 00 00 00 FF 00 00 FF 00 00 FF 00 ..?....?..?..?. 00000160 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 ?..?..?..?..?.. 00000176 FF 00 00 FF 00 00 00 00 FF 00 00 FF 00 00 FF 00 ..?....?..?..?. 00000192 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 ?..?..?..?..?.. 00000208 FF 00 00 FF 00 00 ?..?..

以上即基本的一幅真彩色24位宽10象素高5象素的位图的十六进制格式。我们可以把一幅 位图分为三部分来研究：位图文件头，位图信息头和位图阵列表。 一、位图文件头：

Offset 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

00000000 42 4D D6 00 00 00 00 00 00 00 36 00 00 00 BM?......6... 分析：位图文件头，记录标志文件大小等一些信息。 42 4D 为位图的标志，即ASCII码为BM。

D6 00 表示位图的文件的总字节数。换算成十进制为15054字节，即这幅画的大小为150 54字节。

00 00 00 00 00 00 该几个字节为保留字节。

36 00 00 00 表示位图阵列的起始位置。36H=54即54字节开始为位图阵列。

二、位图信息头：

Offset 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 00000000 28 00 (.

00000016 00 00 0A 00 00 00 05 00 00 00 01 00 18 00 00 00 ................ 00000032 00 00 A0 00 00 00 C4 0E 00 00 C4 0E 00 00 00 00 ..?..?..?.... 00000048 00 00 00 00 00 00 .......

分析：位图信息头，记录着和位图相关的一些信息。如位图长、宽、高等。 28 00 00 00 位图信息头的长度。28H=40，即位图信息头占用40个字节。 0A 00 00 00 位图宽度。我们建立的位图是10个象素所以这里为0AH。 05 00 00 00 位图高度 。刚好等于我们建立位图时设置的5个象素宽的值。 10 00 位图设备级别。

18 00 位图级别00 18H=24即24位真彩色。 00 00 00 00 压缩类型 为0代理不压缩。

A0 00 00 00 位图大小。A0=160 ，代表下面的图阵列表为160个字节 C4 0E 00 00 水平分辨率。 C4 0E 00 00 垂真分辨率。

00 00 00 00 位图实际使用的颜色表中的颜色变址数。 00 00 00 00 位图显示过程中被认为重要颜色变址数。 三、位图阵列表

Offset 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

00000048 00 00 FF 00 00 FF 00 00 FF 00 .?..?..?.

00000064 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 ?..?..?..?..?.. 00000080 FF 00 00 FF 00 00 00 00 FF 00 00 FF 00 00 FF 00 ..?....?..?..?. 00000096 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 ?..?..?..?..?.. 00000112 FF 00 00 FF 00 00 00 00 FF 00 00 FF 00 00 FF 00 ..?....?..?..?. 00000128 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 ?..?..?..?..?.. 00000144 FF 00 00 FF 00 00 00 00 FF 00 00 FF 00 00 FF 00 ..?....?..?..?. 00000160 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 ?..?..?..?..?.. 00000176 FF 00 00 FF 00 00 00 00 FF 00 00 FF 00 00 FF 00 ..?....?..?..?. 00000192 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 ?..?..?..?..?.. 00000208 FF 00 00 FF 00 00 ?..?.. 分析：该区域均为位图阵列表。

在24位位图阵列中，每三个字节代表画笔上的一个象素，这三个字节从左到右分别代表 蓝、绿、红，所以00 00 FF代表一个红色的象素。在位图阵列中就记载了位图显示的位 置和颜色这两个要素。在此例中地址为48开始的三个字节00 00 FF在画笔中呈出来的是 左下角的最左边的一个点。虽然和实际上的位图有所不同但它是按一定规律的。 核心成象原理：

在24位位图阵列表中，每三个字节产生屏幕上的一个象素，每个字节分别控制着蓝、绿 、红三个电子枪的发光强度。我们知道在显示器内部有三个电子枪，如果这三个电子枪 都不发光的情况下这时屏幕上就显示为黑色，此时这三个字节就应该为00 00 00；如果 三个电子枪都各自发最强的光，即产生最强的蓝、绿、红三种光混合在一起就是白色， 这时位图阵列表的三个字节为FF FF FF；如果只是其中的一个电子枪发光则产生的光就 是蓝、绿、红中的其中的一种；如果系统需要其它颜色的话就可能两个或者三个电子枪 都产生强弱不同的光线来组合成其它颜色。在位图阵列表中的这三个字节只是告诉电子 枪要发光的强弱，00代最不发光，FF代表发该电子枪最强的光，这就是为什么这么一段 位图阵列表为什么能够在画笔中呈现出多彩的颜色的基本原理。

以上仅对Windows画笔产生的24位真彩色位图的一个例子来解析位图格式。在VC中的win gdi.h中对于位图的编码和格式有更加详细的定义，下面给出24位真彩位图格式在VC中的 定义。

typedef struct tagBITMAPFILEHEADER { //位图文件头 WORD bfType; //位图标志\"BM\"

DWORD bfSize; //位图文件总字节数 WORD bfReserved1;

WORD bfReserved2; DWORD bfOffBits;

} BITMAPFILEHEADER, FAR *LPBITMAPFILEHEADER, *PBITMAPFILEHEADER; 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, FAR *LPBITMAPINFOHEADER, *PBITMAPINFOHEADER; typedef struct tagRGBTRIPLE { //位图阵列格式定义 BYTE rgbtBlue; //定义蓝色 BYTE rgbtGreen; //定义绿色 BYTE rgbtRed; //定义红色

} RGBTRIPLE; //构成一个3字节的RGBTRIPLE

好了，你现在已经弄懂了24位真彩色位图格式，编码和产生的原理，我想至于图标、以 及jpg等这些文件的探索大家应该能够举一反三，其原理也是24位真彩色位图原理基本一 样，只是其中对其中增压缩算法等一些技术在里面。

三、Pyos所支持的Windows标准的BMP图片格式

BMP图片格式其实不是只单单的一种格式，而是一类格式的总称，这包括皆如24位真彩格式，16位真彩格式，16位真彩格式中又有555格式，565格式等，还有4位，8位调色板格式，压缩存储格式等，非常复杂，本次Pyos只支持了其中的一种，即非压缩的，16位真彩色555格式，这也是现在的32位windows默认的16位BMP格式。由于BMP格式的纷繁复杂，我想有关这方面最权威最全面的资料莫过于通过MSDN获得了，因此，本实验报告并不打算对此进行完整而详尽的描述，本实验报告将只描述本实验所用到的一些细节，以便于你能非常便利的阅读本实验的代码。

下面我们来简单理解一下BMP格式。BMP格式又称之为位图格式，它是把一幅图的色彩信息完整的记录了下来，每个点都用一个色彩于表示，这样在显示的时候，只需要读取此文件，然后获得每个点的色彩数据，然后把这个点用这个色彩显示到屏幕上就行了，由于每幅图都是由一个一个的点构成的，因此，把所有的点都显示完了之后，就完成了整幅图片的显示。

但是，一个文件光记录每个点的色彩信息还不行，还需要记录这个图片的大小，以及这幅图片每个点用几个数据位来记录色彩等信息，这部份信息被称之为BMP文件的头信息，而被记录在文件的开头位置。下面我们就来看看这个文件头：

struct bmp_bmp_head_struct{ short type ; // 类型 int size_file ; // 大小 short reserved_0 ; short reserved_1 ;

int offset ; // 位图阵列的起始位置

struct bmp_bmp_info_head_struct info_head ; } ;

这个结构比较简单，首先是2字节的类型数据，用来认定这是不是一个BMP文件，紧接着是一个4字节的数据，用来表示这个文件的大小，跟着的4字节保留给将来使用，随后的4字节是一个偏移量，这个偏移量指出了每个点的色彩数据在这个BMP文件中的什么位置，这对我们来说非常重要。随后，是一个所谓的BMP信息结构，下面我们就来看看这个所谓的BMP信息结构中到底都有些什么数据值得我们关心。

struct bmp_bmp_info_head_struct{ int the_struct_size ; int width ; int height ;

// 下面还有数据，但目前 pyos 只处理 16 位真彩位图，因此下面的数据不要了 } ;

这个结构也比较简章，首先是4字节的数据，用来表示这个结构的大小，随后的4字节数据给出了这个文件所描述的图片的宽度，紧接着的4个字节给出了这副图片的高度，随后还有一些数据，它们给出了这个图片是否使用了压缩格式来存放数据，每个点是用多少位来表示的，以及是否使用了调色版，如果使用了调色版，后面还有调色版的数据。由于本篇只处理 16 位的真彩位图，所以下面的数据本实验都不考虑了，但是，如果你想做一个更好更完善的系统，那么你需要好好的研究一下BMP完整的格式，然后根据其中所记录的不同信息，在程序中进行不同的处理，pyos只是一个原理性的实验系统，故而，并不打算在此方面多下功夫，非常希望能在以后见到改进版本:P。

有了上面的描述，我们可以对怎么样显示图片有个比较良好的认识了，我们现在来看看pyos中的实际的处理代码：

// 显示 pbmp 格式的图片

void vesa_show_bmp_picture( unsigned int x , unsigned int y , void *bmp_addr , unsigned short mask_color , int dose_use_mask_color )

{

// 这里只支持 windows 标准 16 位 bmp 格式图片，（1:5:5:5）

struct bmp_bmp_head_struct *bmp_head = ( struct bmp_bmp_head_struct * )bmp_addr ; int width = bmp_head->info_head.width ; // 获得图片的宽度 int height = bmp_head->info_head.height ; // 获得图片的高度

// 下面记算存储每个点的色彩的信息所在的位置

unsigned short *color = ( unsigned short * )( ( unsigned int )bmp_addr + bmp_head->offset ) ;

// 由于一行的字节数比须是 4 的倍数，因此，这里先计算每行需要的填充数，除 2 是因为每个像素两个字节

int fill_length = width * 2 % 4 / 2 ;

// bmp 的存放顺序是从下到上，从左到右 for( int i = height - 1 ; i >= 0 ; --i ){ for( int j = 0 ; j < width ; ++j ){ // 取得每个点的色彩信息

// 由于 windows 默认的是 555 格式，而 pyos 用的是 565 格式，因此先进行一下转换

unsigned short temp_color = vesa_change_color_form_555_to_565( *color ) ; if( !dose_use_mask_color || temp_color != mask_color ){

// 画出每个点

vesa_draw_point( x + j , y + i , temp_color ) ; } ++color ; } // 填充

color += fill_length ; }

}

上面的代码也是比较简单的，而且有较为详尽的注释，这里就不多描述了，需要提醒的只有两点：第一，BMP文件存放图片的默认顺序是从一幅图的最左下角开始，从左到右，从下到上，而不是按正常的从上到下的顺序。而且，每存一行数据，都要检测一下是否是4的倍数，如果不是，则填充0，以使它总是4字节的倍数，这也称之为4字节对齐。

第二个需要注意的地方就是，windows默认使用的16位真彩位图是555格式，也就是说红（R）、绿（G）、兰（B）都用5位数据来表示，而pyos现在用的是565格式（即红（R）用5位表示，绿（G）用6位表示，兰（B）用5位表示），因此，在显示之前，需要将其转换一下，具体的内容，可以参看源代码。