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的字節對齊圖片，注意文件結束時最後幾個字節（文件中部的部分不容易分辨）：
