调色板数据根据BMP版本的不同而不同, Palette N * 4 byte 调色板规范。对于调色板中的每个表项，这4个字节用下述方法来描述RGB的值：

1字节用于蓝色分量

1字节用于绿色分量

1字节用于红色分量

1字节用于填充符（设置为0）

根据BMP版本及调色板尺寸的不同而不同， Bitmap Data xxx bytes 该域的大小取决于压缩方法及图像的尺寸和图像的位深度，它包含所有的位图数据字节，这些数据可能是彩色调色板的索引号，也可能是实际的RGB值，这将根据图像信息头中的位深度值来决定。

位图文件头包含有关于文件类型、文件大小、存放位置等信息，在Windows 3.0以上版本的位图文件中用BITMAPFILEHEADER结构来定义：

其中：

bfType：文件的类型.（该值必需是0x4D42，也就是字符'BM'。我们不需要判断OS/2的位图标识，这么做看来似乎已经没有什么意义了，而且如果要支持OS/2的位图，程序将变得很繁琐。所以，在此只建议你检察'BM'标识）

注意：查ascii表'B': 0x42,'M': 0x4d, bfType为两个字节，'B'为low字节，'M'为high字节, 所以bfType=0x4D42，而不是0x424D，但注意这里采用了小端模式，详见大小端模式。

bfSize：文件的大小，用字节为单位

bfReserved1：保留，必须设置为0

bfReserved2：保留，必须设置为0

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

位图信息用BITMAPINFO结构来定义，它由位图信息头（bitmap-information header）和彩色表（color table）组成，前者用BITMAPINFOHEADER结构定义，后者用RGBQUAD结构定义。BITMAPINFO结构具有如下形式：

其中：

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

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

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

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 表示位图最多有65536种颜色。每个色素用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 表示位图最多有1670万种颜色。这种位图没有调色板（bmiColors成员尺寸为0），在位数组中，每3个字节代表一个像素，分别对应于颜色R、G、B。

biBitCount=32 表示位图最多有4294967296(2的32次方)种颜色。这种位图的结构与16位位图结构非常类似，当biCompression成员的值是BI_RGB时，它也没有调色板，32位中有24位用于存放RGB值，顺序是：最高位—保留，红8位、绿8位、蓝8位。这种格式也被成为888 32位图。如果 biCompression成员的值是BI_BITFIELDS时，原来调色板的位置将被三个DWORD变量占据，成为红、绿、蓝掩码，分别用于描述红、绿、蓝分量在32位中所占的位置。在Windows 95/Windows 98中，系统只接受888格式，也就是说三个掩码的值将只能是：0xFF0000、0xFF00、0xFF。而在NT系统中，你只要注意使掩码之间不产生重叠就行。（注：这种图像格式比较规整，因为它是DWORD对齐的，所以在内存中进行图像处理时可进行汇编级的代码优化（简单））。

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，表示都重要。

彩色表定位

应用程序可使用存储在biSize成员中的信息来查找在BITMAPINFO结构中的彩色表，如下所示：

pColor = ((LPSTR) pBitmapInfo + (WORD) (pBitmapInfo->bmiHeader.biSize))

如今Windows(3.x以及95，98，NT)系列已经成为绝大多数用户使用的操作系统，它比DOS成功的一个重要因素是它可视化的漂亮界面。那么Windows是如何显示图像的呢？这就要谈到位图（bitmap）。

我们知道，普通的显示器屏幕是由许许多多点构成的，我们称之为像素。显示时采用扫描的方法：电子枪每次从左到右扫描一行，为每个像素着色，然后从上到下这样扫描若干行，就扫过了一屏。为了防止闪烁，每秒要重复上述过程几十次。例如我们常说的屏幕分辨率为640×480，刷新频率为70Hz，意思是说每行要扫描640个像素，一共有480行，每秒重复扫描屏幕70次。

我们称这种显示器为位映像设备。所谓位映像，就是指一个二维的像素矩阵，而位图就是采用位映像方法显示和存储的图像。举个例子，图1.1是一幅普通的黑白位图，图1.2是被放大后的图，图中每个方格代表了一个像素。我们可以看到：整个骷髅就是由这样一些黑点和白点组成的。

那么，彩色图是怎么回事呢？

我们先来说说三元色RGB概念。

我们知道，自然界中的所有颜色都可以由红、绿、蓝（R，G，B）组合而成。有的颜色含有红色成分多一些，如深红；有的含有红色成分少一些，如浅红。针对含有红色成分的多少，可以分成0到255共256个等级，0级表示不含红色成分；255级表示含有100%的红色成分。同样，绿色和蓝色也被分成256级。这种分级概念称为量化。

这样，根据红、绿、蓝各种不同的组合我们就能表示出256×256×256，约1600万种颜色。这么多颜色对于我们人眼来说已经足够丰富了。

表1.1 常见颜色的RGB组合值

你大概已经明白了，当一幅图中每个像素赋予不同的RGB值时，能呈现出五彩缤纷的颜色了，这样就形成了彩色图。的确是这样的，但实际上的做法还有些差别。

让我们来看看下面的例子。

有一个长宽各为200个像素，颜色数为16色的彩色图，每一个像素都用R、G、B三个分量表示。因为每个分量有256个级别，要用8位（bit），即一个字节（byte）来表示，所以每个像素需要用3个字节。整个图像要用200×200×3，约120k字节，这可不是一个小数目，但是我们用下面的方法，就能省的多。

因为是一个16色图，也就是说这幅图中最多只有16种颜色，我们可以用一个表：表中的每一行记录一种颜色的R、G、B值。这样当我们表示一个像素的颜色时，只需要指出该颜色是在第几行，即该颜色在表中的索引值。举个例子，如果表的第0行为255，0，0（红色），那么当某个像素为红色时，只需要标明0即可。

让我们再来计算一下：16种状态可以用4位（bit）表示，所以一个像素要用半个字节。整个图像要用200×200×0.5，约20k字节，再加上表占用的字节为3×16=48字节.整个占用的字节数约为前面的1/6，省很多吧？

这张R、G、B的表，就是我们常说的调色板（Palette），另一种叫法是颜色查找表LUT（Look Up Table），似乎更确切一些。Windows位图中便用到了调色板技术。其实不光是Windows位图，许多图像文件格式如pcx、tif、gif等都用到了。所以很好地掌握调色板的概念是十分有用的。

有一种图，它的颜色数高达256×256×256种，也就是说包含我们上述提到的R、G、B颜色表示方法中所有的颜色，这种图叫做真彩色图（true color）。真彩色图并不是说一幅图包含了所有的颜色，而是说它具有显示所有颜色的能力，即最多可以包含所有的颜色。表示真彩色图时，每个像素直接用R、G、B三个分量字节表示，而不采用调色板技术。原因很明显：如果用调色板，表示一个像素也要用24位，这是因为每种颜色的索引要用24位（因为总共有2种颜色，即调色板有2行），和直接用R，G，B三个分量表示用的字节数一样，不但没有任何便宜，还要加上一个256×256×256×3个字节的大调色板。所以真彩色图直接用R、G、B三个分量表示，它又叫做24位色图。

编辑 播报

有关RGB三色空间我想大家都很熟悉，这里我想说的是在Windows下，RGB颜色阵列存储的格式其实BGR。也就是说，对于24位的RGB位图像素数据格式是：

对于32位的RGB位图像素数据格式是：

透明通道也称Alpha通道，该值是该像素点的透明属性，取值在0（全透明）到255（不透明）之间。对于24位的图像来说，因为没有Alpha通道，故整个图像都不透明。

加载文件的目的是要得到图片属性，以及RGB数据，然后可以将其绘制在DC上（GDI），或是生成纹理对象（3D:OpenGL/Direct3D）。这两种用途在数据处理上有点区别，我们主要按前一种用法讲，在和3D有不同的地方，我们再提出来。

加载代码

位图信息

这里我们得到了3个重要的图形属性：宽，高，以及每个像素颜色所占用的位数。

行对齐

由于Windows在进行行扫描的时候最小的单位为4个字节，所以当

图片宽 X 每个像素的字节数 ！= 4的整数倍

时要在每行的后面补上缺少的字节，以0填充（一般来说当图像宽度为2的幂时不需要对齐）。位图文件里的数据在写入的时候已经进行了行对齐，也就是说加载的时候不需要再做行对齐。但是这样一来图片数据的长度就不是：宽 X 高 X 每个像素的字节数了，我们需要通过下面的方法计算正确的数据长度：

图片数据

对于24位和32位的位图文件，位图数据的偏移量为sizeof(BITMAPFILEHEADER) + sizeof（BITMAPINFOHEADER），也就是说我们可以直接读取图像数据了。

如果你足够细心，就会发现内存m_pImageData里的数据的确是BGR格式，可以用个纯蓝色或者是纯红色的图片测试一下。

绘制

好了，数据和属性我们都有了，就可以拿来随便用了，就和吃馒头一样，爱粘白糖粘白糖，爱粘红糖粘红糖。下面是我的GDI绘制代码，仅作参考。

不同之处

如果你是想用刚才我们得到的数据生成纹理对象，那么你还要请出下面的问题。

首先，用来生成纹理的数据不需要对齐，也就是说不能在每行的后面加上对齐的字节。当然在OpenGL里要求纹理图片的尺寸为2的幂，所以这个问题实际上不存在；

其次，我们得到的图形数据格式是BGR(BGRA)，所以在生成纹理的时候，需指定格式为GL_BGR_EXT(GL_BGRA_EXT)；否则需要做BGR-RGB（BGRA-RGBA）的转化。