bmp/gif/jpg图象最底层原理分析（１）－－－－ JPG
《探索图像文件的奥秘》，清华大学出版社，1996年
写在前面的
＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊
24位bmp是公认最好的图片存储格式,存储了图片所有的信息
24位bmp是每像素用24位二进制存储该像素点的图像信息，相当于3字节
所以，图像占用空间大小就可以算了{
将图像长宽单位换位像素（比如：1024X960 800X600），则文件大小为 （长X宽X３）字节
如：800X600的图片大小为800X600X3＝1440000字节=1.44兆
1024X960的图像大小为2.95兆
16位bmp则是24为的三分之二大小
8．．．．．．．．．．．．一．．
1．．．．．．．．．24．．１．．
256色是２的８次方，相当于８位的bmp
同理自己根据二进制换算
＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊
１．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图象最底层原理分析（１）－－－－gif(１)
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图象最底层原理分析（１）－－－－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图象最底层原理分析（１）－－－－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的值： |
图象数据 | 根据BMP版本及调色板尺寸的不同而不同 | Bitmap Data | xxx bytes | 该域的大小取决于压缩方法及图像的尺寸和图像的位深度，它包含所有的位图数据字节，这些数据可能是彩色调色板的索引号，也可能是实际的RGB值，这将根据图像信息头中的位深度值来决定。 |
1字节用于蓝色分量 | |
1字节用于绿色分量 | |
1字节用于红色分量 | |
1字节用于填充符(设置为0) |
构件详解
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;
