bmp/gif/jpg图象最底层原理分析

bmp/gif/jpg图象最底层原理分析(1)---- JPG

 

《探索图像文件的奥秘》,清华大学出版社,1996年

 

写在前面的 

***********************************************
24位bmp是公认最好的图片存储格式,存储了图片所有的信息
24位bmp是每像素用24位二进制存储该像素点的图像信息,相当于3字节
所以,图像占用空间大小就可以算了{
           将图像长宽单位换位像素(比如:1024X960 800X600),则文件大小为 (长X宽X3)字节
          如:800X600的图片大小为800X600X3=1440000字节=1.44兆
     1024X960的图像大小为2.95兆
16位bmp则是24为的三分之二大小
8............一..
1.........24..1..
256色是2的8次方,相当于8位的bmp
同理自己根据二进制换算
**********************************************
1.jpg图片压缩过程
jpg压缩比例不固定
本文仅讨论静止图像的压缩基本算法,图像压缩的目的在于以较少的数据来表示图像以节约存储费用,或者传输时间和费用。   
jpeg压缩算法可以用失真的压缩方式来处理图像,但失真的程度却是肉眼所无法辩认的。这也就是为什么jpeg会有如此满意的压缩比例的原因。 下面主要讨论,jpeg基本压缩法。
 
一.jpeg压缩过程 jpeg压缩分四个步骤实现:   
1.颜色模式转换及采样;    2.dct变换;     3.量化;     4.编码。
 
二.

1.颜色模式转换及采样 rgb色彩系统是我们最常用的表示颜色的方式。jpeg采用的是ycbcr色彩系统。

想要用jpeg基本压缩法处理全彩色图像,得先把rgb颜色模式图像数据,转换为ycbcr颜色模式的数据。y代表亮度,cb和cr则代表色度、饱和度。
通过下列计算公式可完成数据转换。   
y=0.2990r+0.5870g+0.1140b    cb=-0.1687r-0.3313g+0.5000b+128   cr=0.5000r-0.4187g-0.0813b+128  
人类的眼晴对低频的数据比对高频的数据具有更高的敏感度,事实上,人类的眼睛对亮度的改变也比对色彩的改变要敏感得多,也就是说y成份的数据是比较重要的。
 
既然cb成份和cr成份的数据比较相对不重要,就可以只取部分数据来处理。
以增加压缩的比例。jpeg通常有两种采样方式:yuv411和yuv422,它们所代表的意义是y、cb和cr三个成份的数据取样比例。
 
2.dct变换 dct变换的全称是离散余弦变换(discrete cosine transform),是指将一组光强数据转换成频率数据,以便得知强度变化的情形。若对高频的数据做些修饰,再转回原来形式的数据时,显然与原始数据有些差异,但是人类的眼睛却是不容易辨认出来。
 
压缩时,将原始图像数据分成8*8数据单元矩阵,
例如亮度值的第一个矩阵内容如下: jpeg将整个亮度矩阵与色度cb矩阵,饱和度cr矩阵,视为一个基本单元称作mcu。每个mcu所包含的矩阵数量不得超过10个。
例如,行和列采样的比例皆为4:2:2,则每个mcu将包含四个亮度矩阵,一个色度矩阵及一个饱和度矩阵。
 
当图像数据分成一个8*8矩阵后,还必须将每个数值减去128,然后一一代入dct变换公式中,即可达到dct变换的目的。图像数据值必须减去128,是因为dct转换公式所接受的数字范围是在-128到+127之间。 dct变换公式: x,y代表图像数据矩阵内某个数值的坐标位置f(x,y)代表图像数据矩阵内的数个数值u,v代表dct变换后矩阵内某个数值的坐标位置f(u,v)代表dct变换后矩阵内的某个数值 u=0 且 v=0 c(u)c(v)=1/1.414 u>0 或 v>0 c(u)c(v)=1 经过dct变换后的矩阵数据自然数为频率系数,这些系数以f(0,0)的值最大,称为dc,其余的63个频率系数则多半是一些接近于0的正负浮点数,一概称之为ac。
 
3、量化 图像数据转换为频率系数后,还得接受一项量化程序,才能进入编码阶段。量化阶段需要两个8*8矩阵数据,一个是专门处理亮度的频率系数,另一个则是针对色度的频率系数,将频率系数除以量化矩阵的值,取得与商数最近的整数,即完成量化。 当频率系数经过量化后,将频率系数由浮点数转变为整数,这才便于执行最后的编码。不过,经过量化阶段后,所有数据只保留整数近似值,也就再度损失了一些数据内容,jpeg提供的量化表如下:
 
4、编码 huffman编码无专利权问题,成为jpeg最常用的编码方式,huffman编码通常是以完整的mcu来进行的。
编码时,每个矩阵数据的dc值与63个ac值,将分别使用不同的huffman编码表,而亮度与色度也需要不同的huffman编码表,所以一共需要四个编码表,才能顺利地完成jpeg编码工作。
dc编码 dc是彩采用差值脉冲编码调制的差值编码法,也就是在同一个图像分量中取得每个dc值与前一个dc值的差值来编码。dc采用差值脉冲编码的主要原因是由于在连续色调的图像中,其差值多半比原值小,对差值进行编码所需的位数,会比对原值进行编码所需的位数少许多。
例如差值为5,它的二进制表示值为101,如果差值为-5,则先改为正整数5,再将其二进制转换成1的补数即可。
 
所谓1的补数,就是将每个bit若值为0,便改成1;bit为1,则变成0。差值5应保留的位数为3,下表即列出差值所应保留的bit数与差值内容的对照。 在差值前端另外加入一些差值的霍夫曼码值,例如亮度差值为5(101)的位数为3,则霍夫曼码值应该是100,两者连接在一起即为100101。下列两份表格分别是亮度和色度dc差值的编码表。根据这两份表格内容,即可为dc差值加上霍夫曼码值,完成dc的编码工作。
ac编码 ac编码方式与dc略有不同,在ac编码之前,首先得将63个ac值按zig-zag排序,即按照下图箭头所指示的顺序串联起来。 63个ac值排列好的,将ac系数转换成中间符号,中间符号表示为rrrr/ssss,rrrr是指第非零的ac之前,其值为0的ac个数,ssss是指ac值所需的位数,ac系数的范围与ssss的对应关系与dc差值bits数与差值内容对照表相似。
 
如果连续为0的ac个数大于15,则用15/0来表示连续的16个0,15/0称为zrl(zero rum length),而(0/0)称为eob(enel of block)用来表示其后所剩余的ac系数皆等于0,以中间符号值作为索引值,从相应的ac编码表中找出适当的霍夫曼码值,再与ac值相连即可。 例如某一组亮度的中间符为5/3,ac值为4,首先以5/3为索引值,从亮度ac的huffman编码表中找到1111111110011110霍夫曼码值,于是加上原来100(4)即是用来取[5,4]的huffman编码1111111110011110100,[5,4]表示ac值为4的前面有5个零。 由于亮度ac,色度ac霍夫曼编码表比较长,在此省略去,有兴趣者可参阅相关书籍。
 
实现上述四个步骤,即完成一幅图像的jpeg压缩。

 

参考资料

[1] 林福宗 《图像文件格式(上)——windows 编程》,清华大学出版社, 1996年

[2] 李振辉、李仁各编著, 《探索图像文件的奥秘》,清华大学出版社,1996年
[3] 黎洪松、成实译  《jpeg静止数据压缩标准》,学苑出版社,1996年

 

 

bmp/gif/jpg图象最底层原理分析(1)----gif(1)

 

1.概述
~~~~~~~~

  GIF(Graphics Interchange Format,图形交换格式)文件是由 CompuServe公司开发的图形文件格式,版权所有,任何商业目的使用均须 CompuServe公司授权。
  GIF图象是基于颜色列表的(存储的数据是该点的颜色对应于颜色列表的索引值),最多只支持8位(256色)。GIF文件内部分成许多存储块,用来存储多幅图象或者是决定图象表现行为的控制块,用以实现动画和交互式应用。GIF文件还通过LZW压缩算法压缩图象数据来减少图象尺寸(关于LZW算法和GIF数据压缩>>...)。

2.GIF文件存储结构
~~~~~~~~~~~~~~~~~~~

  GIF文件内部是按块划分的,包括控制块( Control Block )和数据块(Data Sub-blocks)两种。控制块是控制数据块行为的,根据不同的控制块包含一些不同的控制参数;数据块只包含一些8-bit的字符流,由它前面的控制块来决定它的功能,每个数据块大小从0到255个字节,数据块的第一个字节指出这个数据块大小(字节数),计算数据块的大小时不包括这个字节,所以一个空的数据块有一个字节,那就是数据块的大小0x00。下表是一个数据块的结构:

BYTE 7 6 5 4 3 2 1 0 BIT
0

块大小

Block Size - 块大小,不包括这个这个字节(不计算块大小自身)
1   Data Values - 块数据,8-bit的字符串
2  
...  
254  
255

  一个GIF文件的结构可分为文件头(File Header)、GIF数据流(GIF Data Stream)和文件终结器(Trailer)三个部分。文件头包含GIF文件署名(Signature)和版本号(Version);GIF数据流由控制标识符、图象块(Image Block)和其他的一些扩展块组成;文件终结器只有一个值为0x3B的字符(';')表示文件结束。下表显示了一个GIF文件的组成结构:

  GIF署名 文件头  
  版本号
  逻辑屏幕标识符 GIF数据流  
  全局颜色列表  
  ...  
  图象标识符 图象块  
  图象局部颜色列表图
  基于颜色列表的图象数据  
 
  ...  
  GIF结尾 文件结尾

  下面就具体介绍各个部分:

文件头部分(Header)
~~~~~~~~~~~~~~~~~

GIF署名(Signature)和版本号(Version)
~~~~~~~~~~~~~~~~~~~~~~~~~~~
GIF署名用来确认一个文件是否是GIF格式的文件,这一部分由三个字符组成:"GIF";文件版本号也是由三个字节组成,可以为"87a"或"89a".具体描述见下表:

BYTE 7 6 5 4 3 2 1 0 BIT
1 'G' GIF文件标识
2 'I'
3 'F'
4 '8' GIF文件版本号:87a - 1987年5月
        89a - 1989年7月
5 '7'或'9'
6 'a'

GIF数据流部分(GIF Data Stream)

~~~~~~~~~~~~~~~~~~~~~~~~~~~~

逻辑屏幕标识符(Logical Screen Descriptor)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
这一部分由7个字节组成,定义了GIF图象的大小(Logical Screen Width & Height)、颜色深度(Color Bits)、背景色(Blackground Color Index)以及有无全局颜色列表(Global Color Table)和颜色列表的索引数(Index Count),具体描述见下表:

BYTE 7 6 5 4 3 2 1 0 BIT  
1 逻辑屏幕宽度 像素数,定义GIF图象的宽度
2
3 逻辑屏幕高度 像素数,定义GIF图象的高度
4
5 m cr s pixel 具体描述见下...
6 背景色 背景颜色(在全局颜色列表中的索引,如果没有全局颜色列表,该值没有意义)
7 像素宽高比 像素宽高比(Pixel Aspect Radio)

m - 全局颜色列表标志(Global Color Table Flag),当置位时表示有全局颜色列表,pixel值有意义.
cr - 颜色深度(Color ResoluTion),cr+1确定图象的颜色深度.
s - 分类标志(Sort Flag),如果置位表示全局颜色列表分类排列.
pixel - 全局颜色列表大小,pixel+1确定颜色列表的索引数(2的pixel+1次方).

全局颜色列表(Global Color Table)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
全局颜色列表必须紧跟在逻辑屏幕标识符后面,每个颜色列表索引条目由三个字节组成,按R、G、B的顺序排列。

BYTE 7 6 5 4 3 2 1 0 BIT
1 索引1的红色值  
2 索引1的绿色值  
3 索引1的蓝色值  
4 索引2的红色值  
5 索引2的绿色值  
6 索引2的蓝色值  
7 ...  
                 

图象标识符(Image Descriptor)
~~~~~~~~~~~~~~~~~~~~~~~~~
一个GIF文件内可以包含多幅图象,一幅图象结束之后紧接着下是一幅图象的标识符,图象标识符以0x2C(',')字符开始,定义紧接着它的图象的性质,包括图象相对于逻辑屏幕边界的偏移量、图象大小以及有无局部颜色列表和颜色列表大小,由10个字节组成:

BYTE 7 6 5 4 3 2 1 0 BIT  
1 0 0 1 0 1 1 0 0 图象标识符开始,固定值为','
2 X方向偏移量 必须限定在逻辑屏幕尺寸范围内
3
4 Y方向偏移量
5
6 图象宽度
7
8 图象高度
9
10 m i s r pixel
m - 局部颜色列表标志(Local Color Table Flag) 
         置位时标识紧接在图象标识符之后有一个局部颜色列表,供紧跟在它之后的一幅图象使用;值否时使用全局颜色列表,忽略pixel值。
i - 交织标志(Interlace Flag),置位时图象数据使用交织方式排列(详细描述...),否则使用顺序排列。
s - 分类标志(Sort Flag),如果置位表示紧跟着的局部颜色列表分类排列.
r - 保留,必须初始化为0.
pixel - 局部颜色列表大小(Size of Local Color Table),pixel+1就为颜色列表的位数

局部颜色列表(Local Color Table)
~~~~~~~~~~~~~~~~~~~~~~~~~~
如果上面的局部颜色列表标志置位的话,则需要在这里(紧跟在图象标识符之后)定义一个局部颜色列表以供紧接着它的图象使用,注意使用前应线保存原来的颜色列表,使用结束之后回复原来保存的全局颜色列表。如果一个GIF文件即没有提供全局颜色列表,也没有提供局部颜色列表,可以自己创建一个颜色列表,或使用系统的颜色列表。局部颜色列表的排列方式和全局颜色列表一样:RGBRGB......

基于颜色列表的图象数据(Table-Based Image Data)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
由两部分组成:LZW编码长度(LZW Minimum Code Size)和图象数据(Image Data)。

BYTE 7 6 5 4 3 2 1 0 BIT
1 LZW编码长度 LZW编码初始码表大小的位数,详细描述见LZW编码...

 


...
图象数据,由一个或几个数据块(Data Sub-blocks)组成

数据块

...

 

GIF图象数据使用了LZW压缩算法(详细介绍请看后面的『LZW算法和GIF数据压缩』),大大减小了图象数据的大小。图象数据在压缩前有两种排列格式:连续的和交织的(由图象标识符的交织标志控制)。连续方式按从左到右、从上到下的顺序排列图象的光栅数据;交织图象按下面的方法处理光栅数据:

  

 

bmp/gif/jpg图象最底层原理分析(1)----gif(3)

编码器(Compressor)
~~~~~~~~~~~~~~~~

  编码数据,第一步,初始化一个编译表,假设这个编译表的大小是12位的,也就是最多有4096个单位,另外假设我们有32个不同的字符(也可以认为图象的每个像素最多有32种颜色),表示为a,b,c,d,e...,初始化编译表:第0项为a,第1项为b,第2项为c...一直到第31项,我们把这32项就称为根。
  开始编译,先定义一个前缀对象Current Prefix,记为[.c.],现在它是空的,然后定义一个当前字符串Current String,标记为[.c.]k,[.c.]就为Current Prefix,k就为当前读取字符。现在来读取数据流的第一个字符,假如为p,那么Current String就等于[.c.]p(由于[.c.]为空,实际上值就等于p),现在在编译表中查找有没有Current String的值,由于p就是一个根字符,我们已经初始了32个根索引,当然可以找到,把p设为Current Prefix的值,不做任何事继续读取下一个字符,假设为q,Current String就等于[.c.]q(也就是pq),看看在编译表中有没有该值,当然。没有,这时我们要做下面的事情:将Current String的值(也就是pq)添加到编译表的第32项,把Current Prefix的值(也就是p)在编译表中的索引输出到编码流,修改Current Prefix为当前读取的字符(也就是q)。继续往下读,如果在编译表中可以查找到Current String的值([.c.]k),则把Current String的值([.c.]k)赋予Current Prefix;如果查找不到,则添加Current String的值([.c.]k)到编译表,把Current Prefix的值([.c.])在编译表中所对应的索引输出到编码流,同时修改Current Prefix为k ,这样一直循环下去直到数据流结束。伪代码看起来就像下面这样:

编码器伪代码
Initialize String Table;
[.c.] = Empty;
[.c.]k = First Character in CharStream;
while ([.c.]k != EOF )
{
  if ( [.c.]k is in the StringTable)
  {
    [.c.] = [.c.]k;
  }
  else
  {
    add [.c.]k to the StringTable;
    Output the Index of [.c.] in the StringTable to the CodeStream;
    [.c.] = k;
  }
  [.c.]k = Next Character in CharStream;
}
Output the Index of [.c.] in the StringTable to the CodeStream;

来看一个具体的例子,我们有一个字母表a,b,c,d.有一个输入的字符流abacaba。现在来初始化编译表:#0=a,#1=b,#2=c,#3=d.现在开始读取第一个字符a,[.c.]a=a,可以在在编译表中找到,修改[.c.]=a;不做任何事继续读取第二个字符b,[.c.]b=ab,在编译表中不能找,那么添加[.c.]b到编译表:#4=ab,同时输出[.c.](也就是a)的索引#0到编码流,修改[.c.]=b;读下一个字符a,[.c.]a=ba,在编译表中不能找到:添加编译表#5=ba,输出[.c.]的索引#1到编码流,修改[.c.]=a;读下一个字符c,[.c.]c=ac,在编译表中不能找到:添加编译表#6=ac,输出[.c.]的索引#0到编码流,修改[.c.]=c;读下一个字符a,[.c.]c=ca,在编译表中不能找到:添加编译表#7=ca,输出[.c.]的索引#2到编码流,修改[.c.]=a;读下一个字符b,[.c.]b=ab,编译表的#4=ab,修改[.c.]=ab;读取最后一个字符a,[.c.]a=aba,在编译表中不能找到:添加编译表#8=aba,输出[.c.]的索引#4到编码流,修改[.c.]=a;好了,现在没有数据了,输出[.c.]的值a的索引#0到编码流,这样最后的输出结果就是:#0#1#0#2#4#0.

解码器(Decompressor)
~~~~~~~~~~~~~~~~~~

  好了,现在来看看解码数据。数据的解码,其实就是数据编码的逆向过程,要从已经编译的数据(编码流)中找出编译表,然后对照编译表还原图象的光栅数据。
  首先,还是要初始化编译表。GIF文件的图象数据的第一个字节存储的就是LZW编码的编码大小(一般等于图象的位数),根据编码大小,初始化编译表的根条目(从0到2的编码大小次方),然后定义一个当前编码Current Code,记作[code],定义一个Old Code,记作[old]。读取第一个编码到[code],这是一个根编码,在编译表中可以找到,把该编码所对应的字符输出到数据流,[old]=[code];读取下一个编码到[code],这就有两种情况:在编译表中有或没有该编码,我们先来看第一种情况:先输出当前编码[code]所对应的字符串到数据流,然后把[old]所对应的字符(串)当成前缀prefix [...],当前编码[code]所对应的字符串的第一个字符当成k,组合起来当前字符串Current String就为[...]k,把[...]k添加到编译表,修改[old]=[code],读下一个编码;我们来看看在编译表中找不到该编码的情况,回想一下编码情况:如果数据流中有一个p[...]p[...]pq这样的字符串,p[...]在编译表中而p[...]p不在,编译器将输出p[...]的索引而添加p[...]p到编译表,下一个字符串p[...]p就可以在编译表中找到了,而p[...]pq不在编译表中,同样将输出p[...]p的索引值而添加p[...]pq到编译表,这样看来,解码器总比编码器『慢一步』,当我们遇到p[...]p所对应的索引时,我们不知到该索引对应的字符串(在解码器的编译表中还没有该索引,事实上,这个索引将在下一步添加),这时需要用猜测法:现在假设上面的p[...]所对应的索引值是#58,那么上面的字符串经过编译之后是#58#59,我们在解码器中读到#59时,编译表的最大索引只有#58,#59所对应的字符串就等于#58所对应的字符串(也就是p[...])加上这个字符串的第一个字符(也就是p),也就是p[...]p。事实上,这种猜测法是很准确(有点不好理解,仔细想一想吧)。上面的解码过程用伪代码表示就像下面这样:

解码器伪代码 Initialize String Table;
[code] = First Code in the CodeStream;
Output the String for [code] to the CharStream;
[old] = [code];
[code] = Next Code in the CodeStream;
while ([code] != EOF )
{
  if ( [code] is in the StringTable)
  {
    Output the String for [code] to the CharStream; // 输出[code]所对应的字符串
    [...] = translation for [old]; // [old]所对应的字符串
    k = first character of translation for [code]; // [code]所对应的字符串的第一个字符
    add [...]k to the StringTable;
    [old] = [code]; 
  }
  else
  {
    [...] = translation for [old]; 
    k = first character of [...]; 
    Output [...]k to CharStream;
    add [...]k to the StringTable;
    [old] = [code]; 
  }
  [code] = Next Code in the CodeStream;
}

GIF数据压缩
~~~~~~~~~~~

下面是GIF文件的图象数据结构:


BYTE 7 6 5 4 3 2 1 0 BIT
1

编码长度

LZW Code Size - LZW压缩的编码长度,也就是要压缩的数据的位数
  ... 数据块
  块大小 数据块,如果需要可重复多次
  编码数据
  ... 数据块
  块终结器 一个图象的数据编码结束,固定值0

把光栅数据序列(数据流)压缩成GIF文件的图象数据(字符流)可以按下面的步骤进行:
1.定义编码长度
GIF图象数据的第一个字节就是编码长度(Code Size),这个值是指要表现一个像素所需要的最小位数,通常就等于图象的色深;
2.压缩数据
通过LZW压缩算法将图象的光栅数据流压缩成GIF的编码数据流。这里使用的LZW压缩算法是从标准的LZW压缩算法演变过来的,它们之间有如下的差别:
  [1]GIF文件定义了一个编码大小(Clear Code),这个值等于2的『编码长度』次方,在从新开始一个编译表(编译表溢出)时均须输出该值,解码器遇到该值时意味着要从新初始化一个编译表;
  [2]在一个图象的编码数据结束之前(也就是在块终结器的前面),需要输出一个Clear Code+1的值,解码器在遇到该值时就意味着GIF文件的一个图象数据流的结束;
  [3]第一个可用到的编译表索引值是Clear Code+2(从0到Clear Code-1是根索引,再上去两个不可使用,新的索引从Clare Code+2开始添加);
  [4]GIF输出的编码流是不定长的,每个编码的大小从Code Size + 1位到12位,编码的最大值就是4095(编译表需要定义的索引数就是4096),当编码所须的位数超过当前的位数时就把当前位数加1,这就需要在编码或解码时注意到编码长度的改变。
3.编译成字节序列
因为GIF输出的编码流是不定长的,这就需要把它们编译成固定的8-bit长度的字符流,编译顺序是从右往左。下面是一个具体例子:编译5位长度编码到8位字符

0 b b b a a a a a
1 d c c c c c b b
2 e e e e d d d d
3 g g f f f f f e
4 h h h h h g g g
  ...
N                

 
4.打包
  前面讲过,一个GIF的数据块的大小从0到255个字节,第一个字节是这个数据块的大小(字节数),这就需要将编译编后的码数据打包成一个或几个大小不大于255个字节的数据包。然后写入图象数据块中。

 

 

 

 

bmp/gif/jpg图象最底层原理分析(1)----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 { /* bmfh */

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 { /* 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;   

其中: 
  

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对齐的,所以在内存中进行图像处理时可进行汇编级的代码优化(简单))。

(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 04 04 04
05 06 06 06 06 06 06
00 03 45 56 67 00 45 56 67
02 78 78 78
00 02 05 01 从当前位置右移5个位置后向下移一行
02 78 78 78
00 00 行结束
09 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E
00 01 RLE编码图象结束

② BI_RLE4:

编码方式:由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 0 4 0
05 06 0 6 0 6 0
00 06 45 56 67 00 4 5 5 6 6 7
04 78 7 8 7 8
00 02 05 01 从当前位置右移5个位置后向下移一行
04 78 7 8 7 8
00 00 行结束
09 1E 1 E 1 E 1 E 1 E 1
00 01 RLE图象结束

3. 彩色表

彩色表包含的元素与位图所具有的颜色数相同,象素的颜色用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

 

 

 

 

BMP 格式详解

位图文件头的格式:

typedef struct{
int bfType;//bfType(2字节),这里恒定等于&H4D42,ASCII字符'BM'
long bfSize;//文件大小,以4字节为单位
int bfReserve1;//备用
int bfReserve2;//备用
long bfoffBits;//数据区在文件中的位置偏移量
}BITMAPFILEHEADER;//文件头结构体,14字节

typedef struct{
long bitSize;//位图信息头大小
long biWidth;//图象宽度,像素单位
long biHeight;//图象高度,像素单位
          int biPlanes;//位平面树=1
          int biBitCount;//单位像素的位数,表示bmp图片的颜色位数,即24位图、32位图
          long biCompression;//图片的压缩属性,bmp图片是不压缩的,等于0
          long biSizeImage;表示bmp图片数据区的大小,当上一个属性biCompression等于0时,这里的值可以省略不填
          long biXPlosPerMeter;//水平分辨率,可省略
          long biYPlosPerMeter;//垂直分辨率,可省略
          long biClrUsed;//表示使用了多少个颜色索引表,一般biBitCount属性小于16才会用到,等于0时表示有2^biBitCount个颜色索引表
          long biClrImportant;//表示有多少个重要的颜色,等于0时表示所有颜色都很重要
}BITMAPINFOHEADER;//位图信息头,40字节


BMP文件详解(2)2007-03-21 12:26一个bmp文件以BITMAPFILEHEADER结构体开始,BITMAPFILEHEADER的第1个属性是bfType(2字节),这里恒定等于&H4D42。由于内存中的数据排列高位在左,低位在右,所以内存中从左往右看就显示成(42 4D),所以在UltraEdit中头两个 字节显示为(42 4D)就是这样形成的,以后的数据都是这个特点,不再作重复说明。

BITMAPFILEHEADER的第2个属性是bfSize(4字节),表示整个bmp文件的大小,这里等于&H000004F8=1272字节。

BITMAPFILEHEADER的第3个、第4个属性分别是bfReserved1、bfReserved2(各2字节),这里是2个保留属性,都为0,这里等于&H0000、&H0000。

BITMAPFILEHEADER的第5个属性是bfOffBits(4字节),表示DIB数据区在bmp文件中的位置偏移量,这里等于&H00000076=118,表示数据区从文件开始往后数的118字节开始。 
BITMAPFILEHEADER结构体这里就讲完了,大家会发现BITMAPFILEHEADER只占了bmp文件开始的14字节长度,但需要 特别说明的是在vb中定义一个BITMAPFILEHEADER结构体变量,其长度占了16个字节,原因就是第1个属性本来应该只分配2个字节,但实际被 分配了4个字节,多出来2个字节,所以如果想保存一张bmp图片,写入BITMAPFILEHEADER结构体时一定要注意这一点。

接下来是BITMAPINFO结构体部分。BITMAPINFO段由两部分组成:BITMAPINFOHEADER结构体和RGBQUAD结构 体。其中RGBQUAD结构体表示图片的颜色信息,有些时候可以省略,一般的24位图片和32位图片都不带RGBQUAD结构体,因为DIB数据区直接表 示的RGB值,一般4位图片和8位图片才带有RGBQUAD结构体。(多少位的图片就是用多少位来表示一个颜色信息,例如4位图片表示用4个bit来表示 一个颜色信息。)一个bmp文件中有没有RGBQUAD结构体,可以根据前面BITMAPFILEHEADER结构体的第5个属性bfOffBits来判 断,因为BITMAPINFOHEADER结构体长度为40bit,如果BITMAPINFOHEADER结构体结束后还未到DIB数据区的偏移量,就说 明接下来的数据是RGBQUAD结构体部分。这里讲的C:\WINDOWS\Blue Lace 16.bmp是一个4bit图片,所以它带有 RGBQUAD结构体。

下面进入正题BITMAPINFOHEADER部分。

BITMAPINFOHEADER的第1个属性是biSize(4字节),表示BITMAPINFOHEADER结构体的长度,最常见的长度是40字节,UltraEdit中可以看到紧接着的4个字节等于&H00000028=40字节。

BITMAPINFOHEADER的第2个属性是biWidth(4字节),表示bmp图片的宽度,这里等于&H00000030=48像素。

BITMAPINFOHEADER的第3个属性是biHeight(4字节),表示bmp图片的高度,这里等于&H00000030=48像素。

BITMAPINFOHEADER的第4个属性是biPlanes(2字节),表示bmp图片的平面属,显然显示器只有一个平面,所以恒等于1,这里等于&H0001。

BITMAPINFOHEADER的第5个属性是biBitCount(2字节),表示bmp图片的颜色位数,即24位图、32位图等等。这里等于&H0004,表示该图片为4位图。

BITMAPINFOHEADER的第6个属性是biCompression(4字节),表示图片的压缩属性,bmp图片是不压缩的,等于0,所以这里为&H00000000。

BITMAPINFOHEADER的第7个属性是biSizeImage(4字节),表示bmp图片数据区的大小,当上一个熟悉biCompression等于0时,这里的值可以省略不填,所以这里等于&H00000000。

BITMAPINFOHEADER的第8个属性是biXPelsPerMeter(4字节),表示图片X轴每米多少像素,可省略,这里等于&H00000EC3=3779像素/米。

BITMAPINFOHEADER的第9个属性是biYPelsPerMeter(4字节),表示图片Y轴每米多少像素,可省略,这里等于&H00000EC3=3779像素/米。

BITMAPINFOHEADER的第10个属性是biClrUsed(4字节),表示使用了多少个颜色索引表,一般biBitCount属性小于16才会用到,等于0时表示有2^biBitCount个颜色索引表,所以这里仍等于&H00000000。

BITMAPINFOHEADER的第11个属性是biClrImportant(4字节),表示有多少个重要的颜色,等于0时表示所有颜色都很重要,所以这里等于&H00000000。

至此BITMAPINFOHEADER结构体结束。

由于这个图片到这里还未到达DIB数据区的偏移量,所以接下来的部分是RGBQUAD结构体。RGBQUAD结构体由4个字节型数据组成,所以一 个RGBQUAD结构体只占用4字节空间,从左到右每个字节依次表示(蓝色,绿色,红色,未使用)。举例的这个图片我数了数总共有16个RGBQUAD结 构体,由于该图片是4位图,2^4正好等于16,所以它把16种颜色全部都枚举出来了,这些颜色就是一个颜色索引表。颜色索引表编号从0开始,总共16个 颜色,所以编号为0-15。从UltraEdit中可以看到按照顺序,这16个RGBQUAD结构体依次为:

编号:(蓝,绿,红,空)

0号:(00,00,00,00)

1号:(00,00,80,00)

2号:(00,80,00,00)

3号:(00,80,80,00)

4号:(80,00,00,00)

5号:(80,00,80,00)

6号:(80,80,00,00)

7号:(80,80,80,00)

8号:(C0,C0,C0,00)

9号:(00,00,FF,00)

10号:(00,FF,00,00)

11号:(00,FF,FF,00)

12号:(FF,00,00,00)

13号:(FF,00,FF,00)

14号:(FF,FF,00,00)

15号:(FF,FF,FF,00)

为了更直观的表示这些颜色,可以见后面的图片。

到这里,正好满足DIB数据区的偏移量,所以后面的字节就是图片内容了。这里需要提醒的是所有的DIB数据扫描行是上下颠倒的,也就是说一幅图片先绘制底部的像素,再绘制顶部的像素,所以这些DIB数据所表示的像素点就是从图片的左下角开始,一直表示到图片的右上角。

由于这里的图片是4位图片,也就是说4bit就表示一个像素,一个字节有8个bit,所以一个字节能表示2个像素。

从UltraEdit中可以看到,DIB数据区第一个字节是&H44,16进制正好是将2进制数每4个一组书写的,跟4bit图片正好吻 合,所以&H44表示两个像素,高位的4表示第一个像素,低位的4表示第二个像素。这里的4不是表示RGB颜色,而是表示颜色索引号为4,由于索 引号从0开始编号的,所以4表示索引表中第5个颜色,从附图中可以看到索引号为4的是蓝色。这是第一字节,表示的是图片左下角开始2个像素,如果有 PhotoShop打开这个图片可以看到,左下角2个像素取出来的颜色RGB值正好等于索引表中第5个颜色的RGB值。后面的DIB数据以此类推。

至此一个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;

你可能感兴趣的:(C++)