博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
BMP格式
阅读量:5136 次
发布时间:2019-06-13

本文共 10858 字,大约阅读时间需要 36 分钟。

简介
  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作扩展名)。
  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)之间的偏移量
  
[1]图象信息头
  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'标识)
  
注意:
ascii
B 0x42
,M0x4d,bfType 
为两个字节,
B
low
字节,
M
为high字节
所以
bfType=
0x4D42
,而不是
0x424D,但注意
  bfSize
  说明文件的大小,用字节为单位
  bfReserved1
  保留,必须设置为0
  bfReserved2
  保留,必须设置为0
  bfOffBits
  说明从文件头开始到实际的图象数据之间的字节的偏移量。这个参数是非常有用的,因为位图信息头和调色板的长度会根据不同情况而变化,所以你可以用这个偏移值迅速的从文件中读取到位数据。
  2. 位图信息头
  位图信息用BITMAPINFO结构来定义,它由位图信息头(bitmap-information header)和彩色表(color table)组成,前者用BITMAPINFOHEADER结构定义,后者用RGBQUAD结构定义。BITMAPINFO结构具有如下形式:
  typedef struct tagBITMAPINFO {
  BITMAPINFOHEADER bmiHeader;
  RGBQUAD bmiColors[1];
  } BITMAPINFO;
  其中:
  bmiHeader
  说明BITMAPINFOHEADER结构,其中包含了有关位图的尺寸及位格式等信息
  bmiColors
  说明彩色表RGBQUAD结构的阵列,其中包含索引图像的真实RGB值。
  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结构所需要的字数。注:这个值并不一定是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 表示位图最多有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(or 98)中,系统只接受888格式,也就是说三个掩码的值将只能是:0xFF0000、0xFF00、0xFF。而在NT系统中,你只要注意使掩码之间不产生重叠就行。(注:这种
比较规整,因为它是DWORD对齐的,所以在内存中进行图像处理时可进行汇编级的代码优化(简单))。

bmp位图和调色板的概念

  如今Windows(3.x以及95,98,NT)系列已经成为绝大多数用户使用的操作系统,它比DOS成功的一个重要因素是它可视化的漂亮界面。那么Windows是如何显示图象的呢?这就要谈到位图(bitmap)。
  我们知道,普通的显示器屏幕是由许许多多点构成的,我们称之为象素。显示时采用扫描的方法:电子枪每次从左到右扫描一行,为每个象素着色,然后从上到下这样扫描若干行,就扫过了一屏。为了防止闪烁,每秒要重复上述过程几十次。例如我们常说的屏幕分辨率为640×480,刷新频率为70Hz,意思是说每行要扫描640个象素,一共有480行,每秒重复扫描屏幕70次。
  我们称这种显示器为位映象设备。所谓位映象,就是指一个二维的象素矩阵,而位图就是采用位映象方法显示和存储的图象。举个例子,图1.1是一幅普通的黑白位图,图1.2是被放大后的图,图中每个方格代表了一个象素。我们可以看到:整个骷髅就是由这样一些黑点和白点组成的。
  
图1.1 骷髅
1.2 放大后的骷髅位图
那么,彩色图是怎么回事呢?
  我们先来说说三元色RGB概念。
  我们知道,自然界中的所有颜色都可以由红、绿、蓝(R,G,B)组合而成。有的颜色含有红色成分多一些,如深红;有的含有红色成分少一些,如浅红。针对含有红色成分的多少,可以分成0到255共256个等级,0级表示不含红色成分;255级表示含有100%的红色成分。同样,绿色和蓝色也被分成256级。这种分级概念称为量化。
  这样,根据红、绿、蓝各种不同的组合我们就能表示出256×256×256,约1600万种颜色。这么多颜色对于我们人眼来说已经足够丰富了。
  
1.1 
常见颜色的
RGB
组合值
  
颜色 R G B
255 0 0
0 0 255
绿 0 255 0
255 255 0
255 0 255
0 255 255
255 255 255
0 0 0
128 128 128
你大概已经明白了,当一幅图中每个象素赋予不同的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颜色阵列?

  有关RGB三色空间我想大家都很熟悉,这里我想说的是在Windows下,RGB颜色阵列存储的格式其实BGR。也就是说,对于24位的RGB位图像素数据格式是:
  
蓝色B值 绿色G值 红色R值
对于32位的RGB位图像素数据格式是:
  
蓝色B值 绿色G值 红色R值 透明通道A值
透明通道也称Alpha通道,该值是该像素点的透明属性,取值在0(全透明)到255(不透明)之间。对于24位的图像来说,因为没有Alpha通道,故整个图像都不透明。

加载文件

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

1、加载文件头

  //Load the file header
  BITMAPFILEHEADER header;
  memset(&header,0,sizeof(header));
  inf.read((char*)&header,sizeof(header));
  if(header.bfType != 0x4D42)
  return false;
  这个很简单,没有什么好说的。

2、加载位图信息头

  //Load the image information header
  BITMAPINFOHEADER infoheader;
  memset(&infoheader,0,sizeof(infoheader));
  inf.read((char*)&infoheader,sizeof(infoheader));
  m_iImageWidth = infoheader.biWidth;
  m_iImageHeight = infoheader.biHeight;
  m_iBitsPerPixel = infoheader.biBitCount;
  这里我们得到了3各重要的图形属性:宽,高,以及每个像素颜色所占用的位数。

3、行对齐

  由于Windows在进行行扫描的时候最小的单位为4个字节,所以当
  图片宽 X 每个像素的字节数 != 4的整数倍
  时要在每行的后面补上缺少的字节,以0填充(一般来说当图像宽度为2的幂时不需要对齐)。位图文件里的数据在写入的时候已经进行了行对齐,也就是说加载的时候不需要再做行对齐。但是这样一来图片数据的长度就不是:宽 X 高 X 每个像素的字节数了,我们需要通过下面的方法计算正确的数据长度:
  //Calculate the image data size
  int iLineByteCnt = (((m_iImageWidth*m_iBitsPerPixel) + 3) >> 2) << 2;
  m_iImageDataSize = iLineByteCnt * m_iImageHeight;

4、加载图片数据

  对于24位和32位的位图文件,位图数据的偏移量为sizeof(BITMAPFILEHEADER) + sizeof(BITMAPINFOHEADER),也就是说现在我们可以直接读取图像数据了。
  if(m_pImageData) delete []m_pImageData;
  m_pImageData = new unsigned char[m_iImageDataSize];
  inf.read((char*)m_pImageData,m_iImageDataSize);
  如果你足够细心,就会发现内存m_pImageData里的数据的确是BGR格式,可以用个纯蓝色或者是纯红色的图片测试一下。

5、绘制

  好了,数据和属性我们都有了,现在就可以拿来随便用了,就和吃馒头一样,爱粘白糖粘白糖,爱粘红糖粘红糖。下面是我的GDI绘制代码,仅作参考。
  void CImage::DrawImage(HDC hdc,int iLeft,int iTop,int iWidth,int iHeight)
  {
  if(!hdc || m_pImageData == NULL)
  return;
  BITMAPINFO bmi;
  memset(&bmi,0,sizeof(bmi));
  bmi.bmiHeader.biSize = sizeof(BITMAPINFO);
  bmi.bmiHeader.biWidth = m_iImageWidth;
  bmi.bmiHeader.biHeight = m_iImageHeight;
  bmi.bmiHeader.biPlanes = 1;
  bmi.bmiHeader.biBitCount = m_iBitsPerPixel;
  bmi.bmiHeader.biCompression = BI_RGB;
  bmi.bmiHeader.biSizeImage = m_iImageDataSize;
  StretchDIBits(hdc,iLeft,iTop,iWidth,iHeight,
  0,0,m_iImageWidth,m_iImageHeight,
  m_pImageData,&bmi,DIB_RGB_COLORS,SRCCOPY);
  }

6、3D(OpenGL)的不同之处

  如果你是想用刚才我们得到的数据生成纹理对象,那么你还要请出下面的问题。
  首先,用来生成纹理的数据不需要对齐,也就是说不能在每行的后面加上对齐的字节。当然在OpenGL里要求纹理图片的尺寸为2的幂,所以这个问题实际上不存在;
  其次,我们得到的图形数据格式是BGR(BGRA),所以在生成纹理的时候,需指定格式为GL_BGR_EXT(GL_BGRA_EXT);否则需要做BGR->RGB(BGRA->RGBA)的转化。

转载于:https://www.cnblogs.com/mr-totoro/archive/2012/06/05/5785780.html

你可能感兴趣的文章
latex for wordpress(一)
查看>>
如何在maven工程中加载oracle驱动
查看>>
Flask 系列之 SQLAlchemy
查看>>
aboutMe
查看>>
【Debug】IAR在线调试时报错,Warning: Stack pointer is setup to incorrect alignmentStack,芯片使用STM32F103ZET6...
查看>>
一句话说清分布式锁,进程锁,线程锁
查看>>
FastDFS使用
查看>>
服务器解析请求的基本原理
查看>>
[HDU3683 Gomoku]
查看>>
下一代操作系统与软件
查看>>
Python IO模型
查看>>
DataGridView的行的字体颜色变化
查看>>
局域网内手机访问电脑网站注意几点
查看>>
[Serializable]的应用--注册码的生成,加密和验证
查看>>
Android-多线程AsyncTask
查看>>
LeetCode【709. 转换成小写字母】
查看>>
CF992E Nastya and King-Shamans(线段树二分+思维)
查看>>
如果没有按照正常的先装iis后装.net的顺序,可以使用此命令重新注册一下:
查看>>
linux install ftp server
查看>>
alter database databasename set single_user with rollback IMMEDIATE 不成功问题
查看>>