1. BMP图片格式的核心概念与设计逻辑1.1 从一个实际需求说起为什么今天还要聊BMP很多人第一次接触BMP都是在Windows画图里随手另存为的时候。那个体积大得离谱、打开速度也不算快的文件往往被当作“临时格式”用完就删。但如果你做过嵌入式显示、工控上位机、医疗影像存档或者写过MFC界面的图像加载模块就会发现BMP其实是一个绕不开的存在。它结构简单、无压缩、字节序明确几乎任何一门语言都能在半小时内手写一个解析器。这种“笨但可靠”的特性恰恰是它在特定场景下活到今天的原因。BMP全称Bitmap中文叫位图。它本质上就是一块像素数据的容器把每个像素的颜色值按行排列再加上一个描述“这块数据有多大、怎么解释”的文件头。没有复杂的熵编码没有调色板索引的歧义有调色板的情况也写得很直白更没有块结构带来的解析负担。你拿到一个BMP文件用十六进制编辑器打开前几十个字节就能把它的尺寸、位深、数据偏移全部读出来。这种透明性是JPEG、PNG这些格式给不了的。这篇文章面向的读者很明确需要自己动手解析或生成BMP的开发者尤其是做Windows桌面开发、嵌入式GUI、图像处理底层库、以及需要把图像数据喂给硬件显示控制器的工程师。我会从文件结构讲起把每个字段的含义、字节序、对齐规则都拆开说清楚然后给出可运行的解析和生成代码最后分享一些实际项目中踩过的坑。如果你只是想找个库调一下那这篇文章可能偏底层但如果你想真正搞懂BMP里每一个字节在干什么那接下来的内容应该够用。1.2 BMP格式的家族谱系你遇到的到底是哪一种BMP并不是只有一种固定结构。从Windows 1.0时代到现在它演化出了多个版本常见的有BITMAPCOREHEADER、BITMAPINFOHEADER、BITMAPV4HEADER、BITMAPV5HEADER。你平时用画图保存出来的绝大多数是BITMAPINFOHEADER头部固定40字节。这个版本支持1位、4位、8位、16位、24位、32位像素也是兼容性最好的。BITMAPCOREHEADER是早期OS/2和Windows 1.0用的头部只有12字节宽度和高度都是16位无符号整数位深也只支持1、4、8、24。现在基本见不到了但如果你解析老文件时发现头部大小是12就得按这个结构来读否则后面全乱。BITMAPV4HEADER和V5HEADER分别在Windows 95和Windows 98时代引入头部大小分别是108字节和124字节。它们增加了颜色空间信息、gamma值、ICC配置文件相关字段主要服务于色彩管理。V5还多了对透明度掩码的支持。实际项目中如果你只关心像素显示用INFOHEADER就够了但如果要做色彩校正或者处理带Alpha通道的图就得留意V4/V5里的那些扩展字段。判断版本的方法很简单读文件头第15到18字节从0开始计数是14到17这是一个32位小端整数表示DIB头的大小。12就是CORE40就是INFO108就是V4124就是V5。知道这个你就能决定后面按哪个结构去解析。1.3 为什么BMP坚持不压缩设计取舍背后的逻辑BMP诞生于1980年代末那时候CPU算力有限内存也贵但显示适配器的帧缓冲是直接映射到内存的。BMP的设计目标就是让文件内容能尽可能直接地拷贝到显存里不需要解码。所以它选择了无压缩的逐行存储每行像素按从左到右、从下到上的顺序排列默认情况下高度为正时是倒序的后面会细说。这种设计带来的好处是加载一张BMP理论上只需要一次内存拷贝不需要任何解码计算。对于早期的图形界面、游戏、以及后来的工控HMI这意味着极低的CPU占用和确定的加载时间。坏处也很明显文件体积大。一张1920x1080的24位BMP光像素数据就是1920108036,220,800字节接近6MB。如果换成PNG可能只有几百KB。但BMP也支持RLE压缩主要是4位和8位色深下的RLE4和RLE8。这种压缩是行程编码对有大片同色区域的图像有效但对照片类图像几乎没用甚至可能变大。实际项目中我很少见到用RLE的BMP因为兼容性反而会出问题——有些解析器不支持RLE遇到就报错。所以如果你要生成BMP给别人用最稳妥的还是用无压缩的24位或32位。2. BMP文件结构的逐字节拆解2.1 文件头那14个字节里藏着什么BMP文件最开头是BITMAPFILEHEADER固定14字节。虽然叫“文件头”但它其实只负责告诉解析器“这是一个BMP文件”以及“像素数据从哪里开始”。具体字段如下偏移长度字段名说明02bfType固定为0x4D42即ASCII的BM。小端存储时字节序列是42 4D24bfSize整个文件的大小单位字节62bfReserved1保留必须为082bfReserved2保留必须为0104bfOffBits从文件开头到像素数据的偏移量这里最容易踩坑的是bfType的字节序。你在十六进制编辑器里看到的是42 4D但按小端读成16位整数是0x4D42。很多新手写解析器时直接比较前两个字节是否为B和M这没问题但如果用整数比较就得注意大小端。bfSize字段有时候不可靠。我遇到过一些老工具生成的BMPbfSize写的是0或者错误的值。所以解析时不要完全依赖它最好用文件实际大小来校验。bfOffBits则非常重要它告诉你从哪里开始读像素。对于标准的INFOHEADER调色板像素数据的结构这个值通常是1440调色板大小。但如果你遇到V4/V5头或者有ICC配置文件嵌入这个偏移就会更大。所以永远以bfOffBits为准不要自己算。2.2 DIB头描述图像属性的核心区域紧跟在文件头后面的是DIB头最常见的是BITMAPINFOHEADER40字节。这个结构决定了后面像素数据怎么解释。字段如下偏移长度字段名说明04biSize本结构的大小4044biWidth图像宽度单位像素84biHeight图像高度正数表示倒序负数表示正序122biPlanes固定为1142biBitCount每像素位数1/4/8/16/24/32164biCompression压缩方式0BI_RGB无压缩1BI_RLE82BI_RLE43BI_BITFIELDS204biSizeImage像素数据大小无压缩时可设为0244biXPelsPerMeter水平分辨率像素/米284biYPelsPerMeter垂直分辨率像素/米324biClrUsed调色板中实际使用的颜色数0表示使用全部364biClrImportant重要颜色数0表示都重要biHeight的正负是整个BMP里最反直觉的设计之一。当biHeight为正数时像素数据是从下到上存储的也就是说文件里第一行像素实际上是图像的最后一行。当biHeight为负数时才是从上到下。Windows画图保存的BMP默认是正数所以你在内存里直接按行读出来图像是上下颠倒的。很多初学者写加载器时忘了翻转结果图片倒着显示排查半天才发现是这个原因。biBitCount决定了像素的编码方式。1位表示每个像素用1个bit8个像素打包成1字节颜色由调色板索引决定。4位是每字节两个像素。8位是每字节一个像素也是调色板索引。24位是每像素3字节顺序是B、G、R。32位是每像素4字节顺序是B、G、R、AAlpha通道不一定有效很多工具写0。biCompression为0时是无压缩这是最常用的。为3时表示BITFIELDS此时调色板位置会被三个或四个掩码替代用来指定16位或32位像素中R、G、B、A各占哪些位。这个在游戏纹理和高动态范围图像里常见但普通BMP很少用。2.3 调色板索引颜色的查找表当biBitCount小于等于8时像素数据里存的是调色板索引不是实际颜色。调色板紧跟在DIB头后面每个条目4字节顺序是B、G、R、保留字节通常为0。条目数量由biClrUsed决定如果为0则默认是2的biBitCount次方。比如8位就是256个条目4位是16个1位是2个。这里有个细节调色板条目的顺序是BGR不是RGB。很多新手按RGB读结果颜色偏了。另外保留字节虽然叫保留但有些工具会用它存Alpha值不过标准BMP里这个字节应该为0。如果biClrUsed不为0且小于2的biBitCount次方那么调色板只存实际使用的颜色数但像素数据里的索引仍然可能超出这个范围。解析时要做边界检查否则会读到调色板外面的内存。我见过一个案例某设备生成的BMP里biClrUsed写的是0但实际只用了16个颜色解析器按256个条目去读结果把后面的像素数据当成了调色板颜色全乱。2.4 像素数据行对齐是最大的坑像素数据从bfOffBits开始按行存储。每行的大小不是简单的宽度乘以每像素字节数而是要按4字节对齐。也就是说每行占用的字节数必须是4的倍数不足的要补0。这个规则叫“行填充”或“行对齐”。计算公式是行字节数 ((biWidth * biBitCount 31) / 32) * 4。用整数运算就是((biWidth * biBitCount 31) 5) 2。举个例子一张3x3的24位BMP每行像素数据是339字节但按4字节对齐后每行实际占12字节多出来的3字节是填充。所以整个像素数据是31236字节而不是27字节。如果你解析时按9字节一行去读第二行就会错位图像会斜着花掉。对于1位、4位、8位的图像行对齐同样适用。比如一张5x5的8位图每行5字节对齐后是8字节填充3字节。1位图更复杂因为像素是位打包的行对齐是按字节对齐后再补到4字节边界。还有一个容易忽略的点当biHeight为负数时像素数据是从上到下存储的但行对齐规则不变。解析时先按绝对值算出行数然后根据符号决定是否翻转。3. 手写BMP解析器的完整实操3.1 环境准备与工具选型我平时解析BMP主要用Python和C。Python适合快速验证和脚本处理C适合嵌入到实际项目里。这里我用Python来演示因为它的struct模块处理二进制非常方便而且代码可以直接复制运行。你需要Python 3.6以上不需要额外安装库标准库就够了。如果你要用C建议用std::ifstream以二进制模式打开文件然后用memcpy把字节拷到结构体里。注意结构体要对齐否则读出来的字段会错位。Windows下可以用#pragma pack(push,1)来取消对齐。Linux下可以用__attribute__((packed))。调试工具方面我强烈建议装一个十六进制编辑器比如HxD或者010 Editor。010 Editor有BMP模板可以直接把文件结构树状展示出来排查问题时非常直观。另外Windows自带的画图可以另存为不同位深的BMP用来生成测试样本很方便。3.2 读取文件头与DIB头先定义一个函数接收文件路径返回解析后的图像数据。第一步是读前14字节解析文件头。import struct def parse_bmp(filepath): with open(filepath, rb) as f: data f.read() # 文件头 bfType data[0:2] if bfType ! bBM: raise ValueError(不是BMP文件) bfSize struct.unpack(I, data[2:6])[0] bfOffBits struct.unpack(I, data[10:14])[0] # DIB头大小 dib_size struct.unpack(I, data[14:18])[0] if dib_size 40: # BITMAPINFOHEADER width struct.unpack(i, data[18:22])[0] height struct.unpack(i, data[22:26])[0] planes struct.unpack(H, data[26:28])[0] bit_count struct.unpack(H, data[28:30])[0] compression struct.unpack(I, data[30:34])[0] image_size struct.unpack(I, data[34:38])[0] clr_used struct.unpack(I, data[46:50])[0] else: raise ValueError(f暂不支持的DIB头大小: {dib_size}) return { width: width, height: height, bit_count: bit_count, compression: compression, bfOffBits: bfOffBits, clr_used: clr_used, data: data }这段代码里struct.unpack的格式字符串I表示小端无符号32位整数i表示小端有符号32位整数H表示小端无符号16位整数。宽度用有符号是因为有些情况下宽度可能为负虽然很少见高度用有符号是因为要区分正负。注意bfOffBits是从文件开头算的所以后面取像素数据时直接用data[bfOffBits:]就行。3.3 处理调色板与像素数据如果bit_count小于等于8需要先读调色板。调色板条目数由clr_used决定如果为0则用2的bit_count次方。def read_palette(data, dib_size, bit_count, clr_used): if bit_count 8: return None palette_offset 14 dib_size if clr_used 0: clr_used 1 bit_count palette [] for i in range(clr_used): offset palette_offset i * 4 b, g, r, _ data[offset:offset4] palette.append((r, g, b)) return palette像素数据的读取要处理行对齐。先算出行字节数然后逐行读取。def read_pixels(data, bfOffBits, width, height, bit_count): abs_height abs(height) row_size ((width * bit_count 31) // 32) * 4 pixels [] for y in range(abs_height): row_start bfOffBits y * row_size row_data data[row_start:row_start row_size] row_pixels [] if bit_count 24: for x in range(width): b row_data[x*3] g row_data[x*31] r row_data[x*32] row_pixels.append((r, g, b)) elif bit_count 32: for x in range(width): b row_data[x*4] g row_data[x*41] r row_data[x*42] a row_data[x*43] row_pixels.append((r, g, b, a)) elif bit_count 8: for x in range(width): idx row_data[x] row_pixels.append(idx) elif bit_count 4: for x in range(width): byte_idx x // 2 if x % 2 0: idx row_data[byte_idx] 4 else: idx row_data[byte_idx] 0x0F row_pixels.append(idx) elif bit_count 1: for x in range(width): byte_idx x // 8 bit_idx 7 - (x % 8) idx (row_data[byte_idx] bit_idx) 1 row_pixels.append(idx) pixels.append(row_pixels) # 如果height为正需要翻转 if height 0: pixels.reverse() return pixels这段代码里1位图的位顺序是从高位到低位也就是每字节的最高位对应最左边的像素。这个顺序是BMP规范定的不能搞反。4位图是先高4位后低4位也是从左到右。3.4 生成BMP文件从像素数组到文件生成BMP比解析简单因为你可以控制所有字段。下面是一个生成24位BMP的函数。def write_bmp(filepath, width, height, pixels): # pixels是二维列表每个元素是(r,g,b) row_size ((width * 24 31) // 32) * 4 pixel_data_size row_size * height file_size 14 40 pixel_data_size with open(filepath, wb) as f: # 文件头 f.write(bBM) f.write(struct.pack(I, file_size)) f.write(struct.pack(H, 0)) f.write(struct.pack(H, 0)) f.write(struct.pack(I, 14 40)) # DIB头 f.write(struct.pack(I, 40)) f.write(struct.pack(i, width)) f.write(struct.pack(i, height)) f.write(struct.pack(H, 1)) f.write(struct.pack(H, 24)) f.write(struct.pack(I, 0)) f.write(struct.pack(I, pixel_data_size)) f.write(struct.pack(i, 2835)) # 72 DPI f.write(struct.pack(i, 2835)) f.write(struct.pack(I, 0)) f.write(struct.pack(I, 0)) # 像素数据从下到上 for y in range(height - 1, -1, -1): row pixels[y] row_bytes bytearray() for (r, g, b) in row: row_bytes.append(b) row_bytes.append(g) row_bytes.append(r) # 补填充 padding row_size - len(row_bytes) row_bytes.extend(b\x00 * padding) f.write(row_bytes)这里height传正数像素数据从下到上写所以循环是倒序的。如果你想要从上到下的顺序可以把height写成负数然后循环正序。但要注意很多软件对负height的支持不好所以建议还是用正height加倒序写入。生成8位BMP时需要先写调色板再写像素索引。调色板每个条目4字节BGR顺序。像素数据每行也要对齐。4. 实际项目中常见的坑与排查技巧4.1 图像倒置、花屏、颜色错乱三大高频问题图像倒置是最常见的。原因就是biHeight为正时像素从下到上存储而很多解析器默认从上到下读。解决方法就是在读完后翻转行顺序。如果你在内存里直接操作可以在读取时就从最后一行开始读这样就不用额外翻转。花屏通常是行对齐没处理。比如一张宽度不是4的倍数的24位图每行末尾有填充字节如果你按紧密排列去读第二行就会偏移。排查方法是打印每行的起始偏移看看是否等于bfOffBits y * row_size。如果不等就是对齐算错了。颜色错乱多半是BGR和RGB搞反了。BMP像素数据里是B、G、R的顺序调色板也是B、G、R。如果你按RGB读红色和蓝色会互换。另外32位图的Alpha通道很多工具写0如果你直接当透明度用图像会全透明。处理时要么忽略Alpha要么判断是否全0再决定。4.2 不同位深的兼容性处理1位和4位图现在很少见但工控和嵌入式领域还有。处理1位图时位顺序是从高位到低位这个和很多人的直觉相反。4位图是先高4位后低4位。8位图最简单每字节一个索引。16位图有两种RGB555和RGB565。默认情况下如果没有BITFIELDS掩码16位是RGB555即高5位红、中5位绿、低5位蓝最高位忽略。如果有掩码就按掩码来。32位图默认是BGRA但Alpha不一定有效。跨位深转换时要注意精度损失。比如24位转8位需要做颜色量化简单的做法是用调色板但效果一般。如果只是显示可以直接截断低位。4.3 大文件与内存映射的优化思路一张4K的32位BMP3840x2160x4大约是33MB。如果同时加载多张内存压力不小。优化思路有几个一是用内存映射文件只在访问时读入对应页二是流式解析不一次性把像素全读进内存而是按需读取三是如果只是显示可以转成更紧凑的格式再缓存。Python里可以用mmap模块做内存映射。C里可以用CreateFileMapping或者mmap。但要注意BMP的行对齐和倒序存储会让随机访问变得麻烦所以内存映射更适合顺序扫描的场景。4.4 常见问题速查表现象可能原因排查方法解决图像上下颠倒biHeight为正检查biHeight符号翻转行顺序图像斜向花屏行对齐错误计算row_size并对比实际偏移按4字节对齐读取红蓝互换BGR/RGB搞反检查像素读取顺序交换R和B颜色全黑调色板未读或索引越界检查biClrUsed和调色板偏移正确读取调色板图像右侧有杂色填充字节被当成像素检查每行是否多读了填充按width截断32位图全透明Alpha通道为0检查Alpha值忽略Alpha或设为255文件打不开bfType不是BM检查前两字节确认文件格式解析越界bfOffBits错误对比文件实际大小以bfOffBits为准5. BMP在现代开发中的实际应用场景5.1 嵌入式LCD与工控HMI的显示缓冲在嵌入式领域很多LCD控制器要求帧缓冲是连续的像素数组格式往往是RGB565或RGB888。BMP因为无压缩、行对齐明确非常适合直接转换成帧缓冲格式。我做过一个项目STM32驱动ILI9341屏幕图片资源就是BMP转成的C数组。转换工具自己写读BMP按RGB565重新打包生成头文件。这样烧录到Flash里显示时直接DMA搬运CPU占用几乎为零。工控HMI也类似。很多组态软件支持BMP作为背景图因为解析快不需要额外的解码库。在资源受限的WinCE或Linux嵌入式系统上BMP是首选。5.2 Windows桌面开发中的资源嵌入MFC和Win32 API里LoadImage可以直接加载BMP资源。如果你把BMP作为资源编译进exe用LoadBitmap就能拿到HBITMAP句柄。这种方式在对话框背景、工具栏图标、启动画面里很常见。虽然现在PNG更流行但BMP不需要额外的解码器系统原生支持所以在一些老项目维护中还是主流。用MFC显示BMP的典型流程是CImage加载然后Draw到DC。或者用GDI的Bitmap类。如果要做透明效果32位BMP的Alpha通道需要手动处理因为GDI不支持Alpha混合得用GDI或者Direct2D。5.3 图像处理算法验证的中间格式做图像算法时我习惯用BMP作为中间格式。因为无压缩读写不会引入额外误差而且可以用十六进制编辑器直接看像素值。比如做边缘检测输入输出都用BMP方便对比每个像素的变化。OpenCV虽然支持BMP但默认的imread可能会做颜色空间转换所以我会用imread的IMREAD_UNCHANGED标志保持原始数据。另外BMP的简单结构也适合用来测试自己写的图像库。解析一张BMP验证像素值是否正确比调试JPEG解码器容易得多。5.4 跨平台数据交换的“笨办法”有时候需要在不同系统之间传图像但对方系统可能没有常见的图像库。这时候BMP反而是个好选择因为它的规范足够简单任何语言都能手写解析。我遇到过在一个老式工业设备上只能用C语言没有libpng、没有libjpeg但需要显示一张公司Logo。最后就是把Logo转成24位BMP然后用几十行代码解析显示。虽然文件大了点但省去了移植库的麻烦。当然如果网络传输带宽有限BMP的体积是硬伤。这时候可以先压缩再传接收端解压后再解析BMP。或者用RLE压缩的BMP但兼容性要测试好。6. 进阶话题BITFIELDS与色彩管理6.1 BITFIELDS掩码的解析与生成当biCompression为3时DIB头后面会跟三个或四个32位掩码分别指定红、绿、蓝、alpha在像素值中占哪些位。这个机制允许非标准的位分配比如RGB565、ARGB1555等。解析时先读掩码然后对每个像素做位运算提取分量。def apply_bitfields(pixel, masks): r_mask, g_mask, b_mask masks[0], masks[1], masks[2] r (pixel r_mask) (r_mask.bit_length() - 1 - (r_mask -r_mask).bit_length() 1) # 更简单的做法是算移位和缩放 def extract(value, mask): if mask 0: return 0 shift (mask -mask).bit_length() - 1 max_val mask shift return ((value mask) shift) * 255 // max_val return (extract(pixel, r_mask), extract(pixel, g_mask), extract(pixel, b_mask))生成BITFIELDS BMP时要在DIB头后面写掩码然后bfOffBits要相应调整。注意有些解析器不支持BITFIELDS所以如果要做通用交换还是用标准24位最保险。6.2 V4/V5头中的色彩空间信息BITMAPV4HEADER在INFOHEADER基础上增加了颜色空间类型、端点、gamma值等。这些字段主要用于色彩管理普通显示用不到。V5又增加了ICC配置文件相关的偏移和大小。如果你要生成用于印刷或专业影像的BMP这些字段就重要了。但大多数场景下填0或者标准sRGB值就行。解析V4/V5时头部大小是108或124后面的调色板和像素数据偏移要按这个大小算。不要硬编码40否则会读错。6.3 实际项目中的取舍建议如果你的BMP只是内部使用比如嵌入式资源、算法中间结果那就用24位无压缩INFOHEADER兼容性最好代码最简单。如果需要透明度用32位但要注意Alpha通道的处理。如果要做色彩管理再考虑V4/V5。BITFIELDS除非硬件要求否则尽量避开。文件大小方面如果实在嫌大可以用RLE8但一定要测试目标平台的兼容性。我个人的经验是RLE的BMP在Windows画图里能打开但在一些第三方库和嵌入式解析器里会出问题。所以除非有明确需求否则不推荐。最后再分享一个小技巧如果你需要快速查看BMP的头部信息可以用Python的struct写个一行命令或者用file命令。Linux下file命令能直接告诉你BMP的尺寸和位深调试时很方便。Windows下可以用PowerShell读前几个字节但不如装个十六进制编辑器直观。
