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的字节对齐图片，注意文件结束时最后几个字节（文件中部的部分不容易分辨）：
