尧图网页设计 
简介一份由C语言实现的图片格式转换项目面向正在学习图像处理、需要落地PNG/JPEG转BMP功能的C开发者覆盖从解码到编码的完整流程并附带放大、缩小和旋转等额外图像操作。压缩包共有243个文件整体约14.15MB包含.c/.h源码与头文件、.dsp/.dsw工程配置、可直接运行的.exe程序以及用于测试的png/jpg/bmp示例图片结构较清晰。该项目已有2646人学习下载。内容深入PNG的IHDR/IDAT块与zlib解压、JPEG的DCT/量化表标记、BMP文件头与行填充规则同时讲解最近邻/双线性插值和仿射变换适合想掌握C语言图像处理底层原理并借鉴完整工程代码的开发者参考。 有段时间我在嵌入式项目里折腾一块不带图形加速的LCD屏幕系统上跑的是一个轻量级GUI能直接识别的图片格式只有BMP。项目经理丢给我一堆PNG和JPEG格式的UI素材让我“转一下就能用”。我第一反应是这还不简单用图像编辑软件打开再另存为不就行了。但素材有几百张尺寸不统一路径还嵌套了好几层手工一张张另存为能把自己累到怀疑人生。后来我干脆用C语言写了个命令行小工具把PNG、JPEG统一转成BMP批量处理完事。这件事做完之后回头一复盘才发现“图片格式转换”这个需求听起来简单真正做起来全是细节甚至有些坑纯靠搜索引擎都很难快速找到答案。如果你也遇到类似场景——目标设备只认BMP或者想在C/C项目里脱离在线工具自己实现格式转换这篇实战总结应该能帮你省下不少时间。1. 为什么BMP反而成了刚需PNG/JPEG转BMP的真实场景1.1 目标设备不认JPEG只认裸像素现在大家日常接触的图片大多是JPEG和PNG前者压缩率高、适合照片后者支持透明通道、适合UI素材。但这两者在解码上都比BMP复杂太多。JPEG需要做Huffman解码、反量化、逆DCT、颜色空间转换PNG则要处理filter预测和DEFLATE解压。对于嵌入式设备、老式工控屏、单片机驱动的LCD模块来说主频可能只有几百兆甚至几十兆内存紧张芯片里也没集成硬件解码器直接解码JPEG/PNG非常吃力。BMP几乎没有压缩像素数据就是裸的RGB数组没有解码器也能读。很多轻量级GUI和底层显示驱动都选择了BMP作为默认图片格式因为读取BMP只需要按偏移量跳到像素数据区再一行一行搬进显存即可。这也是为什么在2024年了还会有人问“怎么把PNG转成BMP”这种看似古老的问题。1.2 BMP并不像传说中那么“废物”BMP给人的印象一直是“体积大、没压缩、太原始”。但体积大在不少场景下反而是优点——零解压开销内存映射之后可以直接读取像素。调试图像算法时输出BMP也特别方便不需要引入图像解码库写一个十几行的dump函数就能把RGB数据导出来查看。另外BMP的兼容性好到离谱。Windows画图能打开各类Linux图像查看器能打开嵌入式GUI也能打开。我在项目中还见过有人拿BMP做测试数据生成把任意像素矩阵写成BMP再用图像软件肉眼检查算法结果比一个个打印数值直观得多。1.3 转换的本质解码、重排、写文件很多人以为“格式转换”就是改文件后缀把xx.png改成xx.bmp。实际上PNG文件里存储的是经过压缩和过滤的像素流JPEG文件里存的是DCT系数和量化表BMP文件里存的是裸的BGR像素。所谓转换本质上需要三步用解码器把PNG或JPEG解成原始像素数组把像素数据按BMP的存储规则重排行序、字节序、对齐在像素数据前面拼上BMP文件头和信息头写入新文件。这个过程中最容易被忽略的就是第二步——重排。行对齐、BGR顺序、自底向上这三件事任何一个错了生成的BMP要么打不开要么打开后图像歪掉。后面我会逐一展开。2. 解码库选型零依赖单头文件方案是首选2.1 想自己写解码器先掂量掂量PNG的filter算法我见过有人问“能不能不依赖任何库纯手写PNG解码器”。我劝你先冷静一下。PNG的压缩流程是每行像素先做filter预测有None、Sub、Up、Average、Paeth五种然后经过DEFLATE压缩外面再包上CRC校验。其中DEFLATE解压涉及Huffman表和LZ77窗口滑动完整实现一遍差不多要上千行代码。JPEG更不用说Huffman解码、反量化、逆DCT、YCbCr转RGB、色度抽样恢复每一步都够你忙活一星期。如果只是做格式转换工具完全没有必要从零造轮子。选一个合适的解码库把精力放在BMP写入和参数调优上性价比最高。2.2 主流方案对比stb_image、libpng/libjpeg、lodepng我实际接触过这几种方案列个表给大家参考方案支持格式依赖配置难度许可证适用场景stb_imagePNG、JPEG、BMP、GIF等无单头文件低MIT快速原型、小工具、跨平台项目libpng zlib仅PNG需要zlib中zlib/libpng生产环境、需要精细控制PNG细节libjpeg / libjpeg-turbo仅JPEG无中BSD生产环境、需要高性能JPEG解码lodepng仅PNG无单头文件低zlib只需要PNG读写且想控制体积GDI多种格式Windows原生低微软闭源只面向Windows在这个项目里我选了stb_image。理由很简单单头文件零依赖把stb_image.h拖进工程就能用跨平台编译省心它能同时解PNG和JPEG正好覆盖我的输入格式需求MIT许可证也允许我在商业项目里随便用。代价是它的JPEG解码器不如libjpeg-turbo优化得极致但我的工具处理的是UI素材分辨率不高速度完全够用。2.3 引入stb_image只需两步stb_image的使用方式很特别它不是传统意义上的“链接库”而是把整个实现并进你的源文件里。你只需要在任意一个C文件里写#define STB_IMAGE_IMPLEMENTATION #include stb_image.hSTB_IMAGE_IMPLEMENTATION这个宏是开关告诉编译器“把stb_image的函数实现展开到这个编译单元里”。如果你在多个源文件里包含了stb_image.h就必须保证只有一处定义这个宏否则会重复定义报错。这是第一次用stb库的人最容易犯的错。我一般会把导入操作单独放到一个stb_impl.c文件里/* stb_impl.c */ #define STB_IMAGE_IMPLEMENTATION #include stb_image.h其他源文件include头文件就行干净利落。3. 动手实现完整转换代码与三个关键细节3.1 核心实现convert.c我写了一个精简版转换工具核心逻辑都在image_to_bmp函数里。为了可读性我把BMP文件头和信息头定义成了结构体并且用#pragma pack(push, 1)保证结构体字节对齐为1否则编译器会在字段之间插入填充字节文件头就废了。/* convert.c */ #define STB_IMAGE_IMPLEMENTATION #include stb_image.h #include stdio.h #include stdlib.h #include string.h #pragma pack(push, 1) typedef struct { unsigned short bfType; /* 固定 BM */ unsigned int bfSize; /* 整个文件大小 */ unsigned short bfReserved1; unsigned short bfReserved2; unsigned int bfOffBits; /* 像素数据的字节偏移 */ } BITMAPFILEHEADER; typedef struct { unsigned int biSize; /* 本结构体大小固定40 */ int biWidth; /* 图像宽度 */ int biHeight; /* 图像高度正数自底向上负数自顶向下 */ unsigned short biPlanes; /* 固定1 */ unsigned short biBitCount; /* 每像素位数24 */ unsigned int biCompression;/* 0 表示不压缩 */ unsigned int biSizeImage; /* 像素数据大小 */ int biXPelsPerMeter; int biYPelsPerMeter; unsigned int biClrUsed; unsigned int biClrImportant; } BITMAPINFOHEADER; #pragma pack(pop) static int write_bmp(const char *out_path, const unsigned char *rgb_data, int width, int height) { int stride (width * 3 3) ~3; /* 每行需要4字节对齐 */ int aligned_width stride; /* 实际写入每行的字节数 */ int pad stride - width * 3; /* 行尾需要补的字节数 */ BITMAPFILEHEADER fh; BITMAPINFOHEADER ih; memset(fh, 0, sizeof(fh)); memset(ih, 0, sizeof(ih)); fh.bfType 0x4D42; /* BM */ fh.bfOffBits sizeof(BITMAPFILEHEADER) sizeof(BITMAPINFOHEADER); fh.bfSize fh.bfOffBits stride * height; ih.biSize sizeof(BITMAPINFOHEADER); ih.biWidth width; ih.biHeight height; ih.biPlanes 1; ih.biBitCount 24; ih.biCompression 0; ih.biSizeImage stride * height; ih.biXPelsPerMeter 2835; ih.biYPelsPerMeter 2835; FILE *fp fopen(out_path, wb); if (!fp) { perror(fopen); return -1; } fwrite(fh, 1, sizeof(fh), fp); fwrite(ih, 1, sizeof(ih), fp); /* rgb_data是自上而下、RGB顺序 * BMP默认要求自下而上存取且颜色顺序为BGR。 * 所以从最后一行开始写同时交换R和B。 */ for (int y height - 1; y 0; y--) { const unsigned char *row rgb_data (size_t)y * width * 3; for (int x 0; x width; x) { unsigned char r row[x * 3 0]; unsigned char g row[x * 3 1]; unsigned char b row[x * 3 2]; fputc(b, fp); fputc(g, fp); fputc(r, fp); } for (int i 0; i pad; i) { fputc(0, fp); } } fclose(fp); return 0; } int main(int argc, char *argv[]) { if (argc ! 3) { fprintf(stderr, Usage: %s input.png output.bmp\n, argv[0]); return 1; } int w, h, channels; unsigned char *data stbi_load(argv[1], w, h, channels, 3); if (!data) { fprintf(stderr, Failed to load image: %s\n, stbi_failure_reason()); return 2; } if (write_bmp(argv[2], data, w, h) ! 0) { stbi_image_free(data); return 3; } stbi_image_free(data); printf(Converted %s - %s (%dx%d, %d channels)\n, argv[1], argv[2], w, h, channels); return 0; }核心逻辑确实不长但有三个点如果不理解写出来的代码很难一次跑通。3.2 细节一stride行对齐写错图片直接打不开BMP的行字节数必须对齐到4字节。比如宽度是201像素每像素3字节那一行原始数据就是603字节603不能被4整除所以实际每行要补齐到604字节。我用的公式是int stride (width * 3 3) ~3;这个公式等价于(width * 3 3) / 4 * 4但位运算更简洁。需要注意如果不补对齐字节很多看图软件会按错误的stride解析像素轻则图片歪斜重则直接判定文件无效。我在实际测试里专门试过宽199、200、201三种不同像素宽度的图片只有200时不需要padding200*3600600%40另外两个都补了。这个差异肉眼看不出来但十六进制dump文件时每一行末尾都能看到0x00填充字节。3.3 细节二BMP是BGR顺序不是RGBBMP像素通道顺序是BGR这是历史遗留问题——早期的Windows显示硬件就按BGR输出。如果你把stb_image解出来的RGB数据直接写进文件图片会偏色得极其诡异红色变成蓝色蓝色变成红色一眼就能看出来不对。我当时是用一张纯红色纯渐变测试图验证的先dump了原图第一个像素FF 00 00而目标BMP文件里应该是00 00 FF。如果发现dump出来还是FF 00 00那一定就是漏了通道交换。3.4 细节三BMP默认自底向上stb_image读出来是自上而下BMP存储像素时默认第一行是图像的最后一行自底向上也就是左下角是坐标原点。而stb_image解码后的像素数组是从图片左上角开始的。如果你直接把顶部行写在文件最前面BMP查看器会认为那是底部行表现出来就是整张图上下颠倒。我用了两种解法第一种是上面代码里的行序翻转——从height-1开始倒着写第二种是把biHeight写成负数。Windows文档里规定biHeight为负表示自顶向下存储。但是为了最大兼容性我建议还是老老实实翻转行毕竟有些老牌查看器对负高度的支持并不完美。4. 实测验证转换效果与常见问题定位4.1 转换前后差异对比我拿几张不同来源的图片做了实测原始文件原始大小转换后BMP大小宽高显示效果照片.JPG (1920x1080)约380KB约6.2MB1920x1080与原图一致UI图标.PNG (256x256, 带透明通道)约120KB约196KB256x256透明区域显示为黑色测试渐变.PNG (800x600)约85KB约1.4MB800x600与原图一致体积变化符合预期。JPEG转BMP体积膨胀了十几倍毕竟一个有损压缩一个完全裸存PNG转BMP虽然也变大但没有JPEG那么夸张。透明区域变黑是重点这属于“格式能力差异”不是代码bug下面细说。4.2 全黑、偏色、上下颠倒的排查思路这四个问题是我最初调试时几乎全都遇过的每个都有对应特征。全黑或图片打不开优先检查文件头。用十六进制工具打开BMP前两个字节必须是42 4D即ASCII的BM。然后看bfOffBits我这版代码里是5414字节文件头40字节信息头如果这个值不对查看器会跳到错误的位置去读像素。另一个容易翻车的是结构体对齐没有#pragma pack(1)的话编译器在结构体里插入了填充字段bfOffBits就变成了56甚至更大。偏色红蓝互换dump第一个像素如果原图是红色BMP里应该是00 00 FF如果看到FF 00 00就是RGB/BGR没换。这个排查起来最快看一眼字节就知道。上下颠倒最大的特征是BMP打开后图形位置完全反了但颜色正常。这时优先检查写像素的循环顺序和biHeight符号。如果使用负biHeight自适应顶向下某些查看器可能不支持保守做法是倒序写行。带透明通道的PNG转出来黑底这是PNG特有的坑。stb_image如果按4通道方式加载会得到RGBA数据透明区域像素的RGB值可能是0或预乘前的任意值。转成24位BMP后没有存alpha通道这部分就直接显示为黑色。解决办法有两个一是转换为不透明的背景色比如白底我通常会在加载后的像素数组上先做alpha混合再把结果写入BMP二是输出32位BMPbiBitCount设为32每像素4字节把alpha写进最高字节。但注意BMP标准本身对alpha通道的支持很鸡肋很多查看器根本不读那个字节所以我实际还是用“透明区域填白”的方案更多。5. 批量转换与后续扩展从一个工具到一个小框架5.1 批量转换目录下所有图片上面那个convert.c一次只能转一张。我后来写了个批处理版本核心改动是把main的遍历逻辑换成读取目录。Linux/macOS下用opendir/readdirWindows下用FindFirstFile/FindNextFile然后对每个后缀匹配.png或.jpg的文件调用同一个转换函数。命令行设计也很简单convert_dir input_dir output_dir输入输出目录分开输出文件名只要把后缀改成.bmp就行。这样几百张素材的转换跑一遍几秒钟就完成。当然真正做生产工具的话还需要处理文件名冲突、大小写后缀、扫描子目录这些细节但核心转换代码完全不用动。5.2 如果能让stb_image加载失败时给出更明确的错误提示stb_image本身提供了stbi_failure_reason()函数失败时能返回一个人类可读的错误描述。但我在第一次用的时候根本不知道有这个函数图片加载失败就光看到个NULL指针一度以为库没配置对。后来去翻头文件才发现每次stbi_load失败后调stbi_failure_reason()就能看到具体原因比如“cant find header”或者“bad PNG signature”。如果你也在调stb库这个函数值得记住排查问题能快很多。5.3 追求更高性能换libjpeg-turbo或者流式处理我的批处理工具对速度不敏感stb_image足够。但如果转换的是超大JPEG比如单反拍出来的几千万像素照片可以考虑两条路一是把JPEG解码替换成libjpeg-turbo。它的解码性能比stb_image的JPEG实现好不少并且支持逐行扫描输出边解码边把像素写入BMP内存峰值会低很多。代价是引入一个外部依赖编译配置上稍麻烦。二是流式写入。原始代码里stbi_load把整张图一次性读进内存对1920x1080的图来说大约6MB问题不大但如果是4K甚至8K图内存占用会到几十MB。改进思路是分行解码每解出一行像素就转换BGR并写入文件避免一次性持有全图。5.4 想进一步扩展成图像处理小工具有了这个底座后续想加功能很方便。比如在RGB转BGR的过程中顺手做灰度化、亮度调整、颜色反转根本不用改文件格式逻辑只对像素做处理。我在原项目里就加了一个--grayscale参数图片先灰度化再输出BMP用来做LCD屏幕的灰度测试图效果意外地好。把转换流程和数据流想清楚之后这已经不是一个简单的“格式转换工具”了而是一个能对像素做任意操作的小框架。最后再分享一个实际心得如果你也遇到“图片格式转换”这类看起来太基础的需求不要下意识地打开在线转换网站手工操作。花半小时用C语言把它做成一个可复用的命令行工具后续能省下远超半小时的时间。而且踩过那些文件头、行对齐、字节序的坑之后你对图片格式本质的理解会瞬间上一个台阶——不管是做嵌入式还是做图像处理这些知识都会反复用到。本文还有配套的精品资源点击获取 C语言实现PNG/JPEG转BMP：基于stb_image的批量图片格式转换实战
简介一份由C语言实现的图片格式转换项目面向正在学习图像处理、需要落地PNG/JPEG转BMP功能的C开发者覆盖从解码到编码的完整流程并附带放大、缩小和旋转等额外图像操作。压缩包共有243个文件整体约14.15MB包含.c/.h源码与头文件、.dsp/.dsw工程配置、可直接运行的.exe程序以及用于测试的png/jpg/bmp示例图片结构较清晰。该项目已有2646人学习下载。内容深入PNG的IHDR/IDAT块与zlib解压、JPEG的DCT/量化表标记、BMP文件头与行填充规则同时讲解最近邻/双线性插值和仿射变换适合想掌握C语言图像处理底层原理并借鉴完整工程代码的开发者参考。 有段时间我在嵌入式项目里折腾一块不带图形加速的LCD屏幕系统上跑的是一个轻量级GUI能直接识别的图片格式只有BMP。项目经理丢给我一堆PNG和JPEG格式的UI素材让我“转一下就能用”。我第一反应是这还不简单用图像编辑软件打开再另存为不就行了。但素材有几百张尺寸不统一路径还嵌套了好几层手工一张张另存为能把自己累到怀疑人生。后来我干脆用C语言写了个命令行小工具把PNG、JPEG统一转成BMP批量处理完事。这件事做完之后回头一复盘才发现“图片格式转换”这个需求听起来简单真正做起来全是细节甚至有些坑纯靠搜索引擎都很难快速找到答案。如果你也遇到类似场景——目标设备只认BMP或者想在C/C项目里脱离在线工具自己实现格式转换这篇实战总结应该能帮你省下不少时间。1. 为什么BMP反而成了刚需PNG/JPEG转BMP的真实场景1.1 目标设备不认JPEG只认裸像素现在大家日常接触的图片大多是JPEG和PNG前者压缩率高、适合照片后者支持透明通道、适合UI素材。但这两者在解码上都比BMP复杂太多。JPEG需要做Huffman解码、反量化、逆DCT、颜色空间转换PNG则要处理filter预测和DEFLATE解压。对于嵌入式设备、老式工控屏、单片机驱动的LCD模块来说主频可能只有几百兆甚至几十兆内存紧张芯片里也没集成硬件解码器直接解码JPEG/PNG非常吃力。BMP几乎没有压缩像素数据就是裸的RGB数组没有解码器也能读。很多轻量级GUI和底层显示驱动都选择了BMP作为默认图片格式因为读取BMP只需要按偏移量跳到像素数据区再一行一行搬进显存即可。这也是为什么在2024年了还会有人问“怎么把PNG转成BMP”这种看似古老的问题。1.2 BMP并不像传说中那么“废物”BMP给人的印象一直是“体积大、没压缩、太原始”。但体积大在不少场景下反而是优点——零解压开销内存映射之后可以直接读取像素。调试图像算法时输出BMP也特别方便不需要引入图像解码库写一个十几行的dump函数就能把RGB数据导出来查看。另外BMP的兼容性好到离谱。Windows画图能打开各类Linux图像查看器能打开嵌入式GUI也能打开。我在项目中还见过有人拿BMP做测试数据生成把任意像素矩阵写成BMP再用图像软件肉眼检查算法结果比一个个打印数值直观得多。1.3 转换的本质解码、重排、写文件很多人以为“格式转换”就是改文件后缀把xx.png改成xx.bmp。实际上PNG文件里存储的是经过压缩和过滤的像素流JPEG文件里存的是DCT系数和量化表BMP文件里存的是裸的BGR像素。所谓转换本质上需要三步用解码器把PNG或JPEG解成原始像素数组把像素数据按BMP的存储规则重排行序、字节序、对齐在像素数据前面拼上BMP文件头和信息头写入新文件。这个过程中最容易被忽略的就是第二步——重排。行对齐、BGR顺序、自底向上这三件事任何一个错了生成的BMP要么打不开要么打开后图像歪掉。后面我会逐一展开。2. 解码库选型零依赖单头文件方案是首选2.1 想自己写解码器先掂量掂量PNG的filter算法我见过有人问“能不能不依赖任何库纯手写PNG解码器”。我劝你先冷静一下。PNG的压缩流程是每行像素先做filter预测有None、Sub、Up、Average、Paeth五种然后经过DEFLATE压缩外面再包上CRC校验。其中DEFLATE解压涉及Huffman表和LZ77窗口滑动完整实现一遍差不多要上千行代码。JPEG更不用说Huffman解码、反量化、逆DCT、YCbCr转RGB、色度抽样恢复每一步都够你忙活一星期。如果只是做格式转换工具完全没有必要从零造轮子。选一个合适的解码库把精力放在BMP写入和参数调优上性价比最高。2.2 主流方案对比stb_image、libpng/libjpeg、lodepng我实际接触过这几种方案列个表给大家参考方案支持格式依赖配置难度许可证适用场景stb_imagePNG、JPEG、BMP、GIF等无单头文件低MIT快速原型、小工具、跨平台项目libpng zlib仅PNG需要zlib中zlib/libpng生产环境、需要精细控制PNG细节libjpeg / libjpeg-turbo仅JPEG无中BSD生产环境、需要高性能JPEG解码lodepng仅PNG无单头文件低zlib只需要PNG读写且想控制体积GDI多种格式Windows原生低微软闭源只面向Windows在这个项目里我选了stb_image。理由很简单单头文件零依赖把stb_image.h拖进工程就能用跨平台编译省心它能同时解PNG和JPEG正好覆盖我的输入格式需求MIT许可证也允许我在商业项目里随便用。代价是它的JPEG解码器不如libjpeg-turbo优化得极致但我的工具处理的是UI素材分辨率不高速度完全够用。2.3 引入stb_image只需两步stb_image的使用方式很特别它不是传统意义上的“链接库”而是把整个实现并进你的源文件里。你只需要在任意一个C文件里写#define STB_IMAGE_IMPLEMENTATION #include stb_image.hSTB_IMAGE_IMPLEMENTATION这个宏是开关告诉编译器“把stb_image的函数实现展开到这个编译单元里”。如果你在多个源文件里包含了stb_image.h就必须保证只有一处定义这个宏否则会重复定义报错。这是第一次用stb库的人最容易犯的错。我一般会把导入操作单独放到一个stb_impl.c文件里/* stb_impl.c */ #define STB_IMAGE_IMPLEMENTATION #include stb_image.h其他源文件include头文件就行干净利落。3. 动手实现完整转换代码与三个关键细节3.1 核心实现convert.c我写了一个精简版转换工具核心逻辑都在image_to_bmp函数里。为了可读性我把BMP文件头和信息头定义成了结构体并且用#pragma pack(push, 1)保证结构体字节对齐为1否则编译器会在字段之间插入填充字节文件头就废了。/* convert.c */ #define STB_IMAGE_IMPLEMENTATION #include stb_image.h #include stdio.h #include stdlib.h #include string.h #pragma pack(push, 1) typedef struct { unsigned short bfType; /* 固定 BM */ unsigned int bfSize; /* 整个文件大小 */ unsigned short bfReserved1; unsigned short bfReserved2; unsigned int bfOffBits; /* 像素数据的字节偏移 */ } BITMAPFILEHEADER; typedef struct { unsigned int biSize; /* 本结构体大小固定40 */ int biWidth; /* 图像宽度 */ int biHeight; /* 图像高度正数自底向上负数自顶向下 */ unsigned short biPlanes; /* 固定1 */ unsigned short biBitCount; /* 每像素位数24 */ unsigned int biCompression;/* 0 表示不压缩 */ unsigned int biSizeImage; /* 像素数据大小 */ int biXPelsPerMeter; int biYPelsPerMeter; unsigned int biClrUsed; unsigned int biClrImportant; } BITMAPINFOHEADER; #pragma pack(pop) static int write_bmp(const char *out_path, const unsigned char *rgb_data, int width, int height) { int stride (width * 3 3) ~3; /* 每行需要4字节对齐 */ int aligned_width stride; /* 实际写入每行的字节数 */ int pad stride - width * 3; /* 行尾需要补的字节数 */ BITMAPFILEHEADER fh; BITMAPINFOHEADER ih; memset(fh, 0, sizeof(fh)); memset(ih, 0, sizeof(ih)); fh.bfType 0x4D42; /* BM */ fh.bfOffBits sizeof(BITMAPFILEHEADER) sizeof(BITMAPINFOHEADER); fh.bfSize fh.bfOffBits stride * height; ih.biSize sizeof(BITMAPINFOHEADER); ih.biWidth width; ih.biHeight height; ih.biPlanes 1; ih.biBitCount 24; ih.biCompression 0; ih.biSizeImage stride * height; ih.biXPelsPerMeter 2835; ih.biYPelsPerMeter 2835; FILE *fp fopen(out_path, wb); if (!fp) { perror(fopen); return -1; } fwrite(fh, 1, sizeof(fh), fp); fwrite(ih, 1, sizeof(ih), fp); /* rgb_data是自上而下、RGB顺序 * BMP默认要求自下而上存取且颜色顺序为BGR。 * 所以从最后一行开始写同时交换R和B。 */ for (int y height - 1; y 0; y--) { const unsigned char *row rgb_data (size_t)y * width * 3; for (int x 0; x width; x) { unsigned char r row[x * 3 0]; unsigned char g row[x * 3 1]; unsigned char b row[x * 3 2]; fputc(b, fp); fputc(g, fp); fputc(r, fp); } for (int i 0; i pad; i) { fputc(0, fp); } } fclose(fp); return 0; } int main(int argc, char *argv[]) { if (argc ! 3) { fprintf(stderr, Usage: %s input.png output.bmp\n, argv[0]); return 1; } int w, h, channels; unsigned char *data stbi_load(argv[1], w, h, channels, 3); if (!data) { fprintf(stderr, Failed to load image: %s\n, stbi_failure_reason()); return 2; } if (write_bmp(argv[2], data, w, h) ! 0) { stbi_image_free(data); return 3; } stbi_image_free(data); printf(Converted %s - %s (%dx%d, %d channels)\n, argv[1], argv[2], w, h, channels); return 0; }核心逻辑确实不长但有三个点如果不理解写出来的代码很难一次跑通。3.2 细节一stride行对齐写错图片直接打不开BMP的行字节数必须对齐到4字节。比如宽度是201像素每像素3字节那一行原始数据就是603字节603不能被4整除所以实际每行要补齐到604字节。我用的公式是int stride (width * 3 3) ~3;这个公式等价于(width * 3 3) / 4 * 4但位运算更简洁。需要注意如果不补对齐字节很多看图软件会按错误的stride解析像素轻则图片歪斜重则直接判定文件无效。我在实际测试里专门试过宽199、200、201三种不同像素宽度的图片只有200时不需要padding200*3600600%40另外两个都补了。这个差异肉眼看不出来但十六进制dump文件时每一行末尾都能看到0x00填充字节。3.3 细节二BMP是BGR顺序不是RGBBMP像素通道顺序是BGR这是历史遗留问题——早期的Windows显示硬件就按BGR输出。如果你把stb_image解出来的RGB数据直接写进文件图片会偏色得极其诡异红色变成蓝色蓝色变成红色一眼就能看出来不对。我当时是用一张纯红色纯渐变测试图验证的先dump了原图第一个像素FF 00 00而目标BMP文件里应该是00 00 FF。如果发现dump出来还是FF 00 00那一定就是漏了通道交换。3.4 细节三BMP默认自底向上stb_image读出来是自上而下BMP存储像素时默认第一行是图像的最后一行自底向上也就是左下角是坐标原点。而stb_image解码后的像素数组是从图片左上角开始的。如果你直接把顶部行写在文件最前面BMP查看器会认为那是底部行表现出来就是整张图上下颠倒。我用了两种解法第一种是上面代码里的行序翻转——从height-1开始倒着写第二种是把biHeight写成负数。Windows文档里规定biHeight为负表示自顶向下存储。但是为了最大兼容性我建议还是老老实实翻转行毕竟有些老牌查看器对负高度的支持并不完美。4. 实测验证转换效果与常见问题定位4.1 转换前后差异对比我拿几张不同来源的图片做了实测原始文件原始大小转换后BMP大小宽高显示效果照片.JPG (1920x1080)约380KB约6.2MB1920x1080与原图一致UI图标.PNG (256x256, 带透明通道)约120KB约196KB256x256透明区域显示为黑色测试渐变.PNG (800x600)约85KB约1.4MB800x600与原图一致体积变化符合预期。JPEG转BMP体积膨胀了十几倍毕竟一个有损压缩一个完全裸存PNG转BMP虽然也变大但没有JPEG那么夸张。透明区域变黑是重点这属于“格式能力差异”不是代码bug下面细说。4.2 全黑、偏色、上下颠倒的排查思路这四个问题是我最初调试时几乎全都遇过的每个都有对应特征。全黑或图片打不开优先检查文件头。用十六进制工具打开BMP前两个字节必须是42 4D即ASCII的BM。然后看bfOffBits我这版代码里是5414字节文件头40字节信息头如果这个值不对查看器会跳到错误的位置去读像素。另一个容易翻车的是结构体对齐没有#pragma pack(1)的话编译器在结构体里插入了填充字段bfOffBits就变成了56甚至更大。偏色红蓝互换dump第一个像素如果原图是红色BMP里应该是00 00 FF如果看到FF 00 00就是RGB/BGR没换。这个排查起来最快看一眼字节就知道。上下颠倒最大的特征是BMP打开后图形位置完全反了但颜色正常。这时优先检查写像素的循环顺序和biHeight符号。如果使用负biHeight自适应顶向下某些查看器可能不支持保守做法是倒序写行。带透明通道的PNG转出来黑底这是PNG特有的坑。stb_image如果按4通道方式加载会得到RGBA数据透明区域像素的RGB值可能是0或预乘前的任意值。转成24位BMP后没有存alpha通道这部分就直接显示为黑色。解决办法有两个一是转换为不透明的背景色比如白底我通常会在加载后的像素数组上先做alpha混合再把结果写入BMP二是输出32位BMPbiBitCount设为32每像素4字节把alpha写进最高字节。但注意BMP标准本身对alpha通道的支持很鸡肋很多查看器根本不读那个字节所以我实际还是用“透明区域填白”的方案更多。5. 批量转换与后续扩展从一个工具到一个小框架5.1 批量转换目录下所有图片上面那个convert.c一次只能转一张。我后来写了个批处理版本核心改动是把main的遍历逻辑换成读取目录。Linux/macOS下用opendir/readdirWindows下用FindFirstFile/FindNextFile然后对每个后缀匹配.png或.jpg的文件调用同一个转换函数。命令行设计也很简单convert_dir input_dir output_dir输入输出目录分开输出文件名只要把后缀改成.bmp就行。这样几百张素材的转换跑一遍几秒钟就完成。当然真正做生产工具的话还需要处理文件名冲突、大小写后缀、扫描子目录这些细节但核心转换代码完全不用动。5.2 如果能让stb_image加载失败时给出更明确的错误提示stb_image本身提供了stbi_failure_reason()函数失败时能返回一个人类可读的错误描述。但我在第一次用的时候根本不知道有这个函数图片加载失败就光看到个NULL指针一度以为库没配置对。后来去翻头文件才发现每次stbi_load失败后调stbi_failure_reason()就能看到具体原因比如“cant find header”或者“bad PNG signature”。如果你也在调stb库这个函数值得记住排查问题能快很多。5.3 追求更高性能换libjpeg-turbo或者流式处理我的批处理工具对速度不敏感stb_image足够。但如果转换的是超大JPEG比如单反拍出来的几千万像素照片可以考虑两条路一是把JPEG解码替换成libjpeg-turbo。它的解码性能比stb_image的JPEG实现好不少并且支持逐行扫描输出边解码边把像素写入BMP内存峰值会低很多。代价是引入一个外部依赖编译配置上稍麻烦。二是流式写入。原始代码里stbi_load把整张图一次性读进内存对1920x1080的图来说大约6MB问题不大但如果是4K甚至8K图内存占用会到几十MB。改进思路是分行解码每解出一行像素就转换BGR并写入文件避免一次性持有全图。5.4 想进一步扩展成图像处理小工具有了这个底座后续想加功能很方便。比如在RGB转BGR的过程中顺手做灰度化、亮度调整、颜色反转根本不用改文件格式逻辑只对像素做处理。我在原项目里就加了一个--grayscale参数图片先灰度化再输出BMP用来做LCD屏幕的灰度测试图效果意外地好。把转换流程和数据流想清楚之后这已经不是一个简单的“格式转换工具”了而是一个能对像素做任意操作的小框架。最后再分享一个实际心得如果你也遇到“图片格式转换”这类看起来太基础的需求不要下意识地打开在线转换网站手工操作。花半小时用C语言把它做成一个可复用的命令行工具后续能省下远超半小时的时间。而且踩过那些文件头、行对齐、字节序的坑之后你对图片格式本质的理解会瞬间上一个台阶——不管是做嵌入式还是做图像处理这些知识都会反复用到。本文还有配套的精品资源点击获取