图片格式基础：位图（BMP）与压缩格式（JPEG、PNG）的原理、嵌入式环境下的格式选择策略
做嵌入式GUI这些年，我踩过最多的坑，就是图片格式选型。说白了，选错了格式，要么内存爆了，要么界面卡成幻灯片。今天咱们就把BMP、JPEG、PNG这三兄弟的底裤扒干净，看看它们到底怎么工作，在嵌入式环境里又该怎么选。
位图（BMP）：最朴实的“像素搬运工”
BMP格式，我习惯叫它“老实人”。它不搞任何压缩，每个像素的颜色值直接存进文件。你想想看，一个800×480的屏幕，每个像素用24位（RGB各8位）表示，那文件大小就是800×480×3 = 1,152,000字节，约1.1MB。这还没算文件头和信息头。
BMP文件结构（我简化过的版本）：
- 文件头（14字节）： 标识“BM”、文件大小、数据偏移量
- 信息头（40字节）： 宽、高、色深、压缩方式（通常为0）
- 调色板（可选）： 8位及以下色深时使用
- 像素数据： 从下往上、从左到右存储的BGR值
我在一个低端MCU项目里用过BMP做开机logo。当时Flash还剩256KB，一张320×240的24位BMP就要225KB。嗯，这里要注意——BMP的像素数据是从下往上存的，也就是左下角第一个像素。很多新手直接按文件顺序读，结果图像上下颠倒，我当年也干过这事。
我的经验： 如果MCU的RAM足够大，BMP可以直接映射到显存，省去解码步骤。但Flash吃紧时，BMP就是噩梦。我曾经为了省空间，把24位BMP转成16位（RGB565），文件直接砍掉三分之一，人眼几乎看不出区别。
JPEG：有损压缩的“空间魔术师”
JPEG为什么能把照片压到原来的十分之一？因为它利用了人眼的弱点——对亮度敏感，对颜色细节不敏感。它的核心流程，我拆解给你看：
- 颜色空间转换： RGB转YCbCr，Y是亮度，Cb/Cr是色度
- 下采样： 色度通道缩小一半（4:2:0采样），数据量直接减半
- DCT变换： 把8×8像素块从空间域转到频率域
- 量化： 丢掉人眼不敏感的高频分量——这是压缩的关键
- 熵编码： 用霍夫曼编码进一步压缩
避坑指南： 我曾经在一个产品里用JPEG做背景图，每次切换界面都要解码，结果卡了300多毫秒。后来发现JPEG解码需要大量浮点运算，在Cortex-M4上跑得特别慢。解决方案是预解码成RGB565存到外部Flash，或者用硬件JPEG解码器。
JPEG的压缩比可以调节。质量因子Q=90时，压缩比约10:1，肉眼几乎看不出损失。Q=50时，压缩比约20:1，开始出现块状伪影。Q=10时，压缩比约50:1，图像已经没法看了。我在项目中一般用Q=75，平衡体积和画质。
PNG：无损压缩的“细节守护者”
PNG跟JPEG不同，它不丢任何像素信息。它的压缩原理是：
- 过滤（Filtering）： 对每行像素做差分编码，让相邻像素值更接近
- Deflate压缩： 先用LZ77找重复数据，再用霍夫曼编码压缩
PNG特别适合图标、按钮、文字截图这类有大面积纯色块的图像。为什么？因为纯色块经过差分后，会出现大量连续的0值，Deflate压缩效率极高。我做过测试：一张32×32的图标，BMP要3KB，PNG只要800字节。
PNG的Alpha通道： 这是它比JPEG强的地方。PNG支持8位透明度，可以实现平滑的渐变透明效果。我在做智能家居面板时，用PNG做圆形按钮的遮罩，效果比JPEG硬抠图好太多了。
但PNG也有短板——解码内存开销大。一张800×480的PNG图片，解码时需要先解压到内存，再重建图像。如果MCU只有64KB RAM，根本放不下。我建议：小图标用PNG，大背景用JPEG。
嵌入式环境下的格式选择策略
选格式不能只看文件大小，得综合评估四个维度：存储空间、解码速度、内存占用、画质要求。我画了张图，帮你理清思路：
我整理了一个对比表，方便你快速决策：
| 维度 | BMP | JPEG | PNG |
|---|---|---|---|
| 压缩方式 | 无压缩 | 有损（DCT+量化） | 无损（Deflate） |
| 文件大小 | 最大 | 最小（可调） | 中等 |
| 解码速度 | 最快（直接读取） | 慢（浮点运算） | 中等（整数运算） |
| 解码内存 | 最小（逐行读） | 大（需整图缓冲） | 大（需整图缓冲） |
| Alpha透明 | 不支持 | 不支持 | 支持（8位） |
| 适用场景 | 小尺寸、低内存MCU | 照片、大背景 | 图标、按钮、UI元素 |
我的实战建议：
- 如果MCU有硬件JPEG解码器（比如STM32F7系列），大胆用JPEG做背景，解码几乎不占CPU
- 如果RAM小于64KB，别用PNG做大图。我试过一张800×480的PNG，解码时需要1.2MB的中间缓冲区，直接爆了
- 图标资源统一用PNG，配合纹理打包工具（如TexturePacker），可以大幅减少文件数量和加载时间
- BMP只适合做启动logo或调试用，正式产品里尽量别用
我曾经踩过的坑： 在一个智能门锁项目里，我用了JPEG做用户头像。结果每次开门都要解码头像，导致响应延迟。后来改成预解码成RGB565存到外部Flash，速度从500ms降到20ms。记住：解码开销不是文件大小能体现的，一定要实测。
最后说一句：没有万能的格式，只有合适的场景。你想想看，你的产品是跑在Cortex-M0上还是Cortex-A7上？RAM是64KB还是512MB？这些硬件约束直接决定了你的格式选择。我习惯在项目初期就做一张资源预算表，把每张图片的格式、大小、解码时间、内存占用都列出来，一目了然。