转载自：http://www.cnblogs.com/glaivelee/archive/2011/10/10/2205151.html
《探索图像文件的奥秘》，清华大学出版社，1996年
写在前面的
1．颜色模式转换及采样 rgb色彩系统是我们最常用的表示颜色的方式。jpeg采用的是ycbcr色彩系统。
[1] 林福宗 《图像文件格式（上）——windows 编程》，清华大学出版社， 1996年
编码器(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(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的值：
| ||||||||
| 图象数据 | 根据BMP版本及调色板尺寸的不同而不同 | Bitmap Data | xxx bytes | 该域的大小取决于压缩方法及图像的尺寸和图像的位深度，它包含所有的位图数据字节，这些数据可能是彩色调色板的索引号，也可能是实际的RGB值，这将根据图像信息头中的位深度值来决定。 |
构件详解
1. 位图文件头
位图文件头包含有关于文件类型、文件大小、存放位置等信息，在Windows 3.0以上版本的位图文件中用BITMAPFILEHEADER结构来定义：
typedef struct tagBITMAPFILEHEADER { /* bmfh */
UINT bfType;} BITMAPFILEHEADER;
DWORD bfSize;
UINT bfReserved1;
UINT bfReserved2;
DWORD bfOffBits;
其中：
|
|
|
|
|
|
|
|
|
|
2. 位图信息头
位图信息用BITMAPINFO结构来定义，它由位图信息头(bitmap-information header)和彩色表(color table)组成，前者用BITMAPINFOHEADER结构定义，后者用RGBQUAD结构定义。BITMAPINFO结构具有如下形式：
typedef struct tagBITMAPINFO { /* bmi */
BITMAPINFOHEADER bmiHeader;} BITMAPINFO;
RGBQUAD bmiColors[1];
其中：
|
|
|
|
BITMAPINFOHEADER结构包含有位图文件的大小、压缩类型和颜色格式，其结构定义为：
typedef struct tagBITMAPINFOHEADER { /* bmih */
DWORD biSize;} BITMAPINFOHEADER;
LONG biWidth;
LONG biHeight;
WORD biPlanes;
WORD biBitCount;
DWORD biCompression;
DWORD biSizeImage;
LONG biXPelsPerMeter;
LONG biYPelsPerMeter;
DWORD biClrUsed;
DWORD biClrImportant;
其中：
|
| ||||||||
|
| ||||||||
|
| ||||||||
|
| ||||||||
|
| ||||||||
| 说明图象数据压缩的类型。其值可以是下述值之一：
| ||||||||
| 说明图象的大小，以字节为单位。当用BI_RGB格式时，可设置为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 | 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;} RGBQUAD;
BYTE rgbGreen;
BYTE rgbRed;
BYTE rgbReserved;
其中：
|
|
|
|
|
|
|
|
4. 位图数据
紧跟在彩色表之后的是图象数据字节阵列。图象的每一扫描行由表示图象象素的连续的字节组成，每一行的字节数取决于图象的颜色数目和用象素表示的图象宽度。扫描行是由底向上存储的，这就是说，阵列中的第一个字节表示位图左下角的象素，而最后一个字节表示位图右上角的象素。（只针对与倒向DIB，如果是正向DIB，则扫描行是由顶向下存储的），倒向DIB的原点在图像的左下角，而正向DIB的原点在图像的左上角。同时，每一扫描行的字节数必需是4的整倍数，也就是DWORD对齐的。如果你想确保图像的扫描行DWORD对齐，可使用下面的代码：
(((width*biBitCount)+31)>>5)<<2
位图文件头的格式：
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;
896
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
