BMP格式补充(16bbp & 32bbp & 4字节对齐 & pixel data存放顺序)

http://blog.163.com/lyzaily@126/blog/static/424388372008382912359/

BMP格式补充(16bbp & 32bbp & 4字节对齐 & pixel data存放顺序) 

BMP格式补充(16bbp & 32bbp & 4字节对齐)

(DWORD = 4字节)

Bits Per Pixel = 16

最大可以显示2^16色。如果Compression 设置为0（BI_RGB），则Palette为空，
位图数据将是RGB555存放，最高一位保留未使用。
如果Compression 为3（BI_BITFIELDS），Palette为3个DWORD的掩码，分别用
来取出Red，Green，Blue。
BI_BITFIELDS下可能是RGB555，也可能是RGB565，这由掩码决定。

Bits Per Pixel = 32

最大可以显示2^32色。如果Compression 设置为0（BI_RGB），则Palette为空，
位图数据将是RGB888存放，最高一字节保留未使用。
如果Compression 为3（BI_BITFIELDS），Palette为3个DWORD的掩码，分别用
来取出Red，Green，Blue。

4字节对齐

针对1bit,4bit,8bit,16bit,24bit的bmp，32bit bmp一个像素就是4字节，不用对齐。
一个图像有像素宽度（width）和高度2个属性，bmp的4字节对齐是：一行width个
像素的数据长度（字节单位）如果不能被4整除，则用0补齐4字节后再开始存放下一行的
像素数据，如果是最后一行，后面没有数据了，同样要补齐。

有点抽象，上实例：
下面是一个10*10纯白色的8bit bmp的像素数据区，
0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0x00, 0x00,
0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0x00, 0x00,
0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0x00, 0x00,
0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0x00, 0x00,
0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0x00, 0x00,
0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0x00, 0x00,
0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0x00, 0x00,
0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0x00, 0x00,
0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0x00, 0x00,
0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0x00, 0x00
可以看出后面的0x00都是补齐用得数据。

pixel data存放顺序

当BITMAPINFOHEADER的biHeight>0时，为倒序存放，解释如下。（基本上都是倒序存放的）
pixel data  4字节对齐，按扫描线为单位存放，扫描线倒序存放，也就是，第一条稍描
线存放在最后，最后一条稍描线存放在pixel data区域的开始。每个像素的RGB也是倒
叙存放的，即使BGR存放顺序。这就解释了：矩阵的第一字节代表最左下角落的素，
最后一个字节表示右上角的像素。

总结：BMP真是一个boring的结构，情况复杂，处理起来繁琐，基本上没有压缩，
真是一个糟糕的图像格式。