位图分析续

1、  续上次：http://blog.csdn.net/qingchuwudi/article/details/25785307

提出问题

上一篇文章里在最后我说过：PS产生的位图（bmp）文件每个像素都是4字节，第四个字节是用来补位的，但是并没有解释这么做的原因。

我们先看一下windows产生的位图是什么样的。你会疑问：难道不是上一篇说的那样吗？

下面我给详细展示一下：

一、首先随便找两张图片

这里我用lena.bmp和hoses.bmp(万马奔腾的图像)，这个位图是将jpg文件通过画图板转换得来的：

Lena图像略过，因为上一篇文章里有她的相关信息。

Hoses.jpg:

Hoses.bmp:

 

这种通过转化得来的图片是按照windows格式排版生成的。

 

 

二、分析：

1、首先从数学角度分析，提出位图大小计算公式：

用ultraedit打开lena.bmp和hoses.bmp文件，结果如下：

a)        :lena.bmp

仔细看下我标注的头信息，按照我上一篇文章对它进行解析（用windows的程序员计算器计算，注意十六进制的顺序，不懂的看上一篇）：

红色部分——位图大小：786186 bits(位)

橙色部分——宽度：512

蓝色部分——高度：512

由于windows产生的位图RGB依然是3个字节，并没有在像素内填充无效位，故位图的大小可以通过下面的公式计算：

Size=width*height*3+ 54     ①

其中width是位图宽度，height是位图高度,54是头部信息长度（0x36 == 54个字节）。

用这个公式计算lena.bmp大小：512*512*3 +54 = 786486。结果正确！Perfect！

b)：一个例子并不能证明问题的普遍性，再看hoses.bmp:

 

 

红色部分——位图大小：392454 bits(位)

橙色部分——宽度：435

蓝色部分——高度：300

用上面的公式计算lena.bmp大小：435*300*3 +54 = 391554。可是它的实际大小是392454！说明我们的公式有问题，并不通用。

c)：接下来我随便找了八张位图，分析了它们的头部信息（在excle中列出来）：

注意看，他们的理论值和实际值都不相等！

我们再看“处理后信息”这一列：它们的差值和是高度的n倍，n和宽度有关。

 

分析n和宽度的关系：

我们考虑字节对齐，因为windows系统的文件普遍存在字节对齐（方便读写和查找）。

通过分析可以看出来：windows的位图也是4字节对齐的。

提出新的公式：

Size= (width*3 + width%4)*height + 54   ②

其中：%是取模运算，结果是width除4得到的余数。

通过新公式计算的到八张图片的大小——红色部分：

结果完全正确！Perfect!

注：注意看右上角的公式；当然这个过程提出过几次错误的公式，我就不赘述了。

2、分析公式得出结论

通过分析上面的公式②得出下面的结论：

理论一：windows的位图也是有字节对齐的，只是在每一行的最后补齐不足的字节数（n=width%4）

           注：Lena.bmp之所以第一次就通过，完全是一个巧合，①是②的一个特殊情况。

理论二：Photoshop位图每个像素4Bytes（字节），就是为了避免在每行的最后字节对齐

附hoses.bmp的字节对齐图片，注意文件结束时最后几个字节（文件中部的部分不容易分辨）：