c++如何将内存中的Bitmap数据保存为BMP文件【实战】

C++如何将内存中的Bitmap数据保存为BMP文件【实战】

BMP文件需手动构造BITMAPFILEHEADER和BITMAPINFOHEADER头结构，像素数据按BGR顺序、从下到上存储且每行4字节对齐；24位真彩色推荐biBitCount=24、biCompression=BI_RGB，并须翻转内存行序以匹配BMP左下原点规范。

用 BITMAPINFO 和 WriteFile 手动写 BMP 文件头与像素数据

想在Windows平台下把内存里的像素数据存成BMP文件？最直接、也最可控的方法，其实不是去调用那些封装好的GDI/GDI+函数，而是亲自动手，按照BMP的二进制格式从头到尾“组装”一遍。BMP文件结构非常清晰：一个文件头（BITMAPFILEHEADER），紧跟着一个信息头（BITMAPINFOHEADER），如果需要的话还有调色板（RGBQUAD，只有1位、4位或8位图才需要），最后就是像素数据本身了。数据顺序是BGR，并且每行必须用零填充到4字节的整数倍。只要你手头已经有了原始的像素数组（比如一个uint8_t*指针），剩下的就是按部就班地拼接数据，然后写入磁盘文件。

这里有几个关键参数必须弄对：BITMAPINFOHEADER里的biWidth和biHeight决定了图像的尺寸；biBitCount通常设为24（表示24位真彩色，省去处理Alpha通道的麻烦）或32；biCompression务必设为BI_RGB，表示未压缩。还有一个极易出错的点：BMP格式规定像素数据从图像的最底下一行开始存储。如果你的内存数据是常规的“从上到下”顺序（比如大多数CPU渲染的结果），那么在写入前，必须手动把行序翻转过来。

• 计算对齐后的行宽：每行实际占用的字节数 = ((width * biBitCount + 31) / 32) * 4（这个公式确保结果向上对齐到4字节）。
• 计算文件总大小：文件总字节数 = sizeof(BITMAPFILEHEADER) + sizeof(BITMAPINFOHEADER) + pixel_data_size。
• 写入操作：建议使用Windows API CreateFile和WriteFile来执行文件写入。相比C标准库的fwrite，它们能提供更底层的控制，避免潜在的换行符转换或缓冲问题。

24 位 BGR 数据保存时为何图像上下颠倒？

保存出来的图片头朝下了？别慌，这很可能不是你代码的逻辑错误，而是BMP格式本身的“特性”。BMP规范白纸黑字写着：像素数据的第0行，对应的是图片的最底部。如果你的内存数组pixels是按我们习以为常的“第0行是顶部”的光栅顺序排列的，那么直接逐行写入，结果自然就是上下颠倒的。

解决办法很直观：在逐行复制数据时，从源数据的最后一行开始往前读。具体可以这样操作：

立即学习“C++免费学习笔记（深入）”；

for (int y = 0; y < height; ++y) {
    const uint8_t* src_row = pixels + (height - 1 - y) * stride_in_bytes;
    memcpy(dst_row_ptr, src_row, width * 3);
    dst_row_ptr += row_size_padded;
}

这里，stride_in_bytes是你原始内存中每行数据占用的字节数（它可能没有4字节对齐），而row_size_padded则是我们之前计算好的、BMP要求对齐后的行宽。忽略这个翻转步骤，是新手在保存BMP时踩到的最常见的一个“坑”。

BITMAPINFO 中 biSizeImage 字段到底要不要填？

关于biSizeImage这个字段，微软的官方文档说，当压缩方式为BI_RGB且颜色位数不是16位时，你可以把它设为0，系统会自动计算像素数据区的大小。话虽如此，但经验表明，显式地计算并填写这个值是更稳妥的做法。这能避免某些解析器因为字段为0而产生误判或兼容性问题。

需要特别注意的是：biSizeImage仅仅表示像素数据部分的大小，它不包括文件头和信息头。一个常见的混淆点是把它当成了整个文件的大小，或者与文件头中的bfSize（文件总大小）字段搞混了。

• 正确的关联是：bfSize = sizeof(BITMAPFILEHEADER) + sizeof(BITMAPINFOHEADER) + biSizeImage。
• 如果你填写了biSizeImage，却忘了同步更新bfSize，那么用系统自带的“画图”软件打开时，很可能会报错“不是有效的BMP文件”。
• 另外，如果你处理的是32位数据（带Alpha通道），需要确保Alpha通道不被写入BMP。标准的BI_RGB格式并不支持Alpha，强行写入会导致兼容性问题。除非使用BI_BITFIELDS，但那又是另一番复杂故事了。

跨平台保存时为什么不用 Gdiplus::Bitmap::Sa ve？

你可能会问，既然Windows提供了Gdiplus::Bitmap::Sa ve这样现成的函数，为什么还要大费周章地手动构造呢？原因在于依赖和可控性。使用GDI+意味着你的程序必须依赖gdiplus.dll，并且需要先调用GdiplusStartup进行初始化，这在某些场景下显得笨重且线程不安全。更关键的是，它对内存数据的解释可能不符合你的预期——它默认按BGRA顺序处理，而你传入的可能是纯BGR或RGB数组，一不小心就会导致颜色错乱。此外，它内部隐藏了行对齐的细节，在某些图像尺寸下，可能会悄无声息地添加黑色填充边，而你却无从知晓。

相比之下，纯Win32的手动写法没有任何额外依赖，初始化开销为零，并且让你对每一个字节的布局都有完全的掌控权。唯一的“代价”是多写大约50行C++代码。但话说回来，这50行代码一旦写对，其稳定性和可移植性极高，可以说放之二十年而皆准。

真正的挑战，其实不在于填充那几个结构体，而在于行对齐的计算和上下翻转的逻辑，是否与你原始数据的布局严丝合缝。举个例子，哪怕是一个常见的1920像素宽度，计算(1920*3+31)/32*4得到的是5760。如果这里算错成了5764，就意味着每行会多写4个字节，导致后续所有行的偏移全部错位，整个图像也就面目全非了。细节，才是成败的关键。