#define WIDTHBYTES(bits) (((bits) + 31) / 32 * 4)我的第一个博客

之前看过一些博客，觉得有的写的真的很厉害，但是没想过自己也会写，后来慢慢发现这些博客其实是一种资源，方便自己以后的知识积累，于是也试着创建啦。

看看这个问题：

#define WIDTHBYTES(bits) (((bits) + 31) / 32 * 4)
我上学期做数字图像处理的时候就遇到过这个问题，那么是怎么回事呢？
其实4字节对齐是为了在32位系统下运算速度更快.
这样来说64位系统一般会调整为8字节对其的,也就是 (((bits) + 63) / 64 * 8)了.
这个宏的作用是向上补足为4的倍数，比如传入1，2，3，4都得到4，传入5，6，7，8都得到8
我记得在图像处理上用到了这个宏，为的是4字节对齐。
1个字节是8位，4个字节就是32位，((bits) + 31) / 32向上取整，31就是为了向上取整

1Byte = 8Bits（一字节等于八位）
这个你明白吧？这就好办了。

想得到的就是BYTES嘛，但是计算中间单位是4Bytes，这个明白吧？就是说即使是1Bits也作为4Bytes来看待，因为是“大于或等于biWidth的，离4最近的整倍数”嘛。

4Bytes的单位，就是32Bits的单位，所以，让它除以32就得到了当下的4的整倍数，但是，如果有余数就必须给结果再增加1，既然这样，不如在做除法之前就把它加进去，这样，给bits加上31，确保只要有余数，结果就会加1。最后要得到Bytes值，需要给这个中间单位再*4.

详解：

位图数据记录了位图的每一个像素值或该对应像素的颜色表的索引值，图像记录顺序是在扫描行内是从左到右,扫描行之间是从下到上。这种格式我们又称为Bottom_Up位图，当然与之相对的还有Up_Down形式的位图，它的记录顺序是从上到下的，对于这种形式的位图，也不存在压缩形式。位图的一个像素值所占的字节数：当biBitCount=1时，8个像素占1个字节（二色图）；当biBitCount=4时，2个像素占1个字节；当biBitCount=8时，1个像素占1个字节(灰度图或256色图)；当biBitCount=24时,1个像素占3个字节，此时图像为真彩色图像。当图像不是为真彩色时，图像文件中包含颜色表，位图的数据表示对应像素点在颜色表中相应的索引值，当为真彩色时，每一个像素用三个字节表示图像相应像素点彩色值，每个字节分别对应R、G、B分量的值，这时候图像文件中没有颜色表。上面我已经讲过了，Windows规定图像文件中一个扫描行所占的字节数必须是4的倍数(即以字为单位),不足的以0填充，图像文件中一个扫描行所占的字节数计算方法：

DataSizePerLine= (biWidth* biBitCount+31)/32*4；// 一个扫描行所占的字节数

最主要是/32*4而不能直接/8，见下面例子

举一个例子，对于2色图，如果图象宽(每行像素数)是31，则每一行需要31位存储（对于2色图是每个像素占一位），合3个字节加7位，因为字节数必须是4的整倍数，所以应该是4，而此时biWidth=31,biBitCount=1,WIDTHBYTES(31*1)=(31+31)/32*4=62/32*4=1*4=4，和我们设想的一样。再举一个256色的例子，如果图象宽(每行像素数)是31，则每一行需要31个字节存储（对于256色图是每个像素占8位即一个字节），因为字节数必须是4的整倍数，所以应该是32，而此时的biWidth=31,biBitCount=8,WIDTHBYTES(31*8)=（31*8+31）/32*4=31*9/32*4=279/32*4=8*4=32