格式"/>

【基础】BMP格式

BMP格式

• 位图 (BMP)简介
• 1. 格式
• • 1.1图和调色板的概念
  • 1.2 bmp文件格式
  • • 1.2.1 位图文件头 14字节
    • 1.2.2 位图信息头 40字节
    • 1.2.3 调色板
    • 1.2.4 注意
• 2. 4字节对齐

位图 (BMP)简介

BMP取自位图Bitmap的缩写，也称为DIB（与设备无关的位图），是一种独立于显示器的位图数字图像文件格式。常见于微软视窗和OS/2操作系统，Windows GDI API内部使用的DIB数据结构与 BMP 文件格式几乎相同。

图像通常保存的颜色深度有2（1位）、16（4位）、256（8位）、65536（16位）和1670万（24位）种颜色（其中位是表示每点所用的数据位）
8位图像可以是索引彩色图像外，也可以是灰阶图像。表示透明的alpha通道也可以保存在一个类似于灰阶图像的独立文件中。

BMP文件通常是不压缩的，所以它们通常比同一幅图像的压缩图像文件格式要大很多。例如，一个800×600的24位几乎占据1.4MB空间。因此它们通常不适合在因特网或者其他低速或者有容量限制的介质上进行传输。

根据颜色深度的不同，图像上的一个像素可以用一个或者多个字节表示，它由n/8所确定（n是位深度，1字节包含8个数据位）

1. 格式

1.1图和调色板的概念

如今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万种颜色。这么多颜色对于我们人眼来说已经足够丰富了。

你大概已经明白了，当一幅图中每个象素赋予不同的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 UpTable)，似乎更确切一些。Windows位图中便用到了调色板技术。其实不光是Windows位图，许多图象文件格式如pcx、tif、gif等都用到了。所以很好地掌握调色板的概念是十分有用的。

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

1.2 bmp文件格式

介绍完位图和调色板的概念，下面就让我们来看一看Windows的位图文件(.bmp文件)的格式是什么样子的。

bmp文件大体上分成四个部分，如图1.3所示。

1.2.1 位图文件头 14字节

第一部分为位图文件头BITMAPFILEHEADER，是一个结构，其定义如下：

typedef struct tagBITMAPFILEHEADER {
WORD          bfType;
DWORD         bfSize;
WORD          bfReserved1;
WORD          bfReserved2;
DWORDbfOffBits;
}BITMAPFILEHEADER;

这个结构的长度是固定的，为14个字节(WORD为无符号16位整数，DWORD为无符号32位整数)，各个域的说明如下：

bfType

指定文件类型，必须是0x424D，即字符串“BM”，也就是说所有.bmp文件的头两个字节都是“BM”。

bfSize

指定文件大小，包括这14个字节。

bfReserved1，bfReserved2

为保留字，不用考虑

bfOffBits

为从文件头到实际的位图数据的偏移字节数，即图1.3中前三个部分的长度之和。

1.2.2 位图信息头 40字节

第二部分为位图信息头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;

这个结构的长度是固定的，为40个字节(LONG为32位整数)，各个域的说明如下：

biSize

指定这个结构的长度，为40。

biWidth

指定图象的宽度，单位是象素。

biHeight

指定图象的高度，单位是象素。

biPlanes

必须是1，不用考虑。

biBitCount

指定表示颜色时要用到的位数，常用的值为1(黑白二色图), 4(16色图), 8(256色), 24(真彩色图)(新的.bmp格式支持32位色，这里就不做讨论了)。

biCompression

指定位图是否压缩，有效的值为BI_RGB，BI_RLE8，BI_RLE4，BI_BITFIELDS(都是一些Windows定义好的常量)。要说明的是，Windows位图可以采用RLE4，和RLE8的压缩格式，但用的不多。我们今后所讨论的只有第一种不压缩的情况，即biCompression为BI_RGB的情况。

biSizeImage

指定实际的位图数据占用的字节数，其实也可以从以下的公式中计算出来：

biSizeImage=biWidth’ × biHeight

要注意的是：上述公式中的biWidth’必须是4的整倍数(所以不是biWidth，而是biWidth’，表示大于或等于biWidth的，最接近4的整倍数。举个例子，如果biWidth=240，则biWidth’=240；如果biWidth=241，biWidth’=244)。

如果biCompression为BI_RGB，则该项可能为零

biXPelsPerMeter

指定目标设备的水平分辨率，单位是每米的象素个数，关于分辨率的概念，我们将在第4章详细介绍。

biYPelsPerMeter

指定目标设备的垂直分辨率，单位同上。

biClrUsed

指定本图象实际用到的颜色数，如果该值为零，则用到的颜色数为2biBitCount。

biClrImportant

指定本图象中重要的颜色数，如果该值为零，则认为所有的颜色都是重要的。

1.2.3 调色板

第三部分为调色板Palette，当然，这里是对那些需要调色板的位图文件而言的。有些位图，如真彩色图，前面已经讲过，是不需要调色板的，BITMAPINFOHEADER后直接是位图数据。

调色板实际上是一个数组，共有biClrUsed个元素(如果该值为零，则有2biBitCount个元素)。数组中每个元素的类型是一个RGBQUAD结构，占4个字节，其定义如下：

typedef struct tagRGBQUAD {
BYTE rgbBlue; //该颜色的蓝色分量
BYTE rgbGreen; //该颜色的绿色分量
BYTE rgbRed; //该颜色的红色分量
BYTE rgbReserved; //保留值
} RGBQUAD;

第四部分就是实际的图象数据了。对于用到调色板的位图，图象数据就是该象素颜在调色板中的索引值。对于真彩色图，图象数据就是实际的R、G、B值。下面针对2色、16色、256色位图和真彩色位图分别介绍。

对于2色位图，用1位就可以表示该象素的颜色(一般0表示黑，1表示白)，所以一个字节可以表示8个象素。

对于16色位图，用4位可以表示一个象素的颜色，所以一个字节可以表示2个象素。

对于256色位图，一个字节刚好可以表示1个象素。

对于真彩色图，三个字节才能表示1个象素，哇，好费空间呀！没办法，谁叫你想让图的颜色显得更亮丽呢，有得必有失嘛。

1.2.4 注意

(1) 每一行的字节数必须是4的整倍数，如果不是，则需要补齐。这在前面介绍biSizeImage时已经提到了。

(2) 一般来说，.bMP文件的数据从下到上，从左到右的。也就是说，从文件中最先读到的是图象最下面一行的左边第一个象素，然后是左边第二个象素……接下来是倒数第二行左边第一个象素，左边第二个象素……依次类推，最后得到的是最上面一行的最右一个象素。

2. 4字节对齐

计算图像每行的字节数公式

(width * bitCounts + 31) / 32 * 4

来自于这样一个公式

(width * bitCounts / 8 + 3) / 4 * 4

该公式含义比上面的公式要容易理解一些，比如biWidth * biBitCount代表了对齐前每行的总位数，位图有1位、2位、4位、8位、16位、24位、32位等，大于8位的都是8的倍数，所以biWidth * biBitCount / 8是对齐前的总字节数，要4字节对齐，除以4，看余数多少，不够多少补多少。而因为除以4的余数只能是0、1、2、3这四种情况，0就是刚好整除不需要再补，1、2、3分别需要补3、2、1个字节才能凑足4字节。那么我们在除之前先补上3个字节会是什么情况呢，对于四种余数情形，分别是余3（3+0）、0（3+1）、1（3+2）、2（3+3），对于整数操作(width * bitCounts / 8 + 3) / 4得到的结果不会有余数，刚好达到了我们需要补足4字节的目的；
（个人理解：0+3/4余3，1+3/4余0，2+3/4余1，3+3/4余2；有用的都保留了，余的都没用）
（4/3=1，“/”两边都是整数时，结果也是整数；自动向上转型造成的？）
另外再考虑能不能先补上别的数字，例如1、2，根据前面余数情况分析，补1会漏掉余数为1、2的情况，补2会漏掉余数为1的情况；再考虑补上4或者更大数字的情况，余数为0的情形补4就多了4字节，数字再往上就更加多余，所以补上最大余数刚刚合适。

上面的分析对于位宽大于等于8的位图已经正确，但小于8位的情况，width * bitCounts不一定是8的整数倍，所以我们先不要除以8，而是按照4字节等于32个bit位来计算，我们看看需要补多少位使得刚好32位对齐，那么就有公式：

（width * bitCounts + n）/ 32 * 4

跟1中的分析方法相同，n应为32的最大余数31，所以得到最终公式

（width * bitCounts + 31）/ 32 * 4。