1. 项目背景与核心价值
去年在嵌入式UI开发时遇到一个棘手问题：项目需要显示大量图标但Flash空间只剩30KB。当我尝试把24位色PNG图标转存到设备时，发现单张100x100的图片就要占用近30KB。这时一位老工程师建议："试试RGB565吧，能省一半空间"。这个偶然的对话，开启了我对RGB565格式的深度探索。
RGB565是一种16位的彩色图像编码格式，通过精妙的比特分配方案，在保证可用色彩范围的前提下，将传统RGB24格式的存储需求直接压缩三分之一。具体来说：
- R（红色）通道分配5bit（32级）
- G（绿色）通道分配6bit（64级）
- B（蓝色）通道分配5bit（32级）
这种分配方式充分利用了人眼对绿色更敏感的特性，在几乎不损失视觉观感的情况下实现了高效压缩。
2. 编码原理深度解析
2.1 比特分配策略
理解RGB565的核心在于掌握其比特分布规则。以一个像素值为例：
原始RGB888格式：R=201(0xC9), G=102(0x66), B=153(0x99)
转换过程如下：
-
右移截断（关键操作）：
- R: 201 >> 3 = 25 (保留高5位)
- G: 102 >> 2 = 25 (保留高6位)
- B: 153 >> 3 = 19 (保留高5位)
-
比特拼接：
- 16位值 = (R << 11) | (G << 5) | B
- 即：25<<11 | 25<<5 | 19 = 0x1CE3
注意：不同平台可能存在字节序差异，ARM通常采用小端模式存储
2.2 色彩还原算法
解码时的逆向操作同样重要：
c复制uint16_t rgb565 = 0x1CE3;
uint8_t r = (rgb565 >> 11) & 0x1F; // 取出高5位
uint8_t g = (rgb565 >> 5) & 0x3F; // 取出中间6位
uint8_t b = rgb565 & 0x1F; // 取出低5位
// 扩展到8位（简单版）
uint8_t r8 = (r << 3) | (r >> 2);
uint8_t g8 = (g << 2) | (g >> 4);
uint8_t b8 = (b << 3) | (b >> 2);
这种还原算法虽然会损失部分色彩精度，但实测显示在5寸以下屏幕上人眼几乎无法分辨差异。
3. 实战编码实现
3.1 Python转换工具
开发时我常用这个Python工具进行批量转换：
python复制from PIL import Image
import numpy as np
def convert_to_rgb565(src_path, dst_path):
img = Image.open(src_path).convert('RGB')
arr = np.array(img)
# 关键转换步骤
r = (arr[..., 0] >> 3).astype(np.uint16) << 11
g = (arr[..., 1] >> 2).astype(np.uint16) << 5
b = (arr[..., 2] >> 3).astype(np.uint16)
rgb565 = r | g | b
# 保存为二进制文件
with open(dst_path, 'wb') as f:
f.write(rgb565.tobytes())
3.2 嵌入式端解码优化
在STM32上解码时发现直接计算耗时严重，改用查表法后性能提升8倍：
c复制// 预先计算的扩展表
const uint8_t r5_to_r8[32] = {0,8,16,...,248};
const uint8_t g6_to_g8[64] = {0,4,8,...,252};
const uint8_t b5_to_b8[32] = {0,8,16,...,248};
void draw_pixel(uint16_t x, uint16_t y, uint16_t color) {
uint8_t r = r5_to_r8[(color >> 11) & 0x1F];
uint8_t g = g6_to_g8[(color >> 5) & 0x3F];
uint8_t b = b5_to_b8[color & 0x1F];
LCD_DrawPoint(x, y, RGB(r,g,b));
}
4. 性能对比实测
通过实际项目数据对比不同方案的性能表现：
| 指标 | RGB888原始 | RGB565简单转换 | RGB565优化方案 |
|---|---|---|---|
| 存储空间(KB) | 307.2 | 204.8 | 204.8 |
| 解码速度(FPS) | 62 | 55 | 89 |
| 内存占用(KB) | 900 | 600 | 600 |
| 色彩差异(ΔE) | 0 | 3.2 | 3.2 |
实测发现三个关键现象：
- 在480x272分辨率的屏幕上，ΔE<5的色彩差异人眼基本无法察觉
- 使用DMA传输配合RGB565格式，刷新率可突破100FPS
- 启用STM32的硬件加速后，解码耗时降低至原来的1/20
5. 进阶应用技巧
5.1 透明通道模拟
虽然RGB565不支持透明通道，但可以通过特殊颜色值实现：
c复制#define TRANS_COLOR 0xF81F // 品红色作为透明色
void draw_image_with_trans(uint16_t* img_data, int w, int h) {
for(int y=0; y<h; y++) {
for(int x=0; x<w; x++) {
uint16_t color = img_data[y*w + x];
if(color != TRANS_COLOR) {
draw_pixel(x, y, color);
}
}
}
}
5.2 动态调色板技术
针对色彩简单的UI元素，可以进一步压缩：
- 提取图像中的主要颜色构建16色调色板
- 每个像素用4bit索引代替16bit颜色值
- 实际显示时通过LUT转换为RGB565
这种方法可以将存储需求再降低75%，特别适合仪表盘等场景。
6. 踩坑实录与解决方案
问题1：色彩带状现象
当连续渐变时出现明显色阶，解决方案：
- 添加抖动处理：在转换时对误差进行扩散
- 使用Floyd-Steinberg算法优化
问题2：端序不一致
PC端生成的文件在嵌入式设备显示异常：
- 统一使用__packed关键字定义结构体
- 文件头添加字节序标记（0xFFFE或0xFEFF）
问题3：性能瓶颈
大尺寸图片解码卡顿：
- 改用行缓冲而非全图缓冲
- 利用STM32的CRC模块校验数据完整性
- 启用DCache时注意内存对齐问题
经过三个版本迭代，最终形成的RGB565处理流程已经应用在多个量产项目中。最成功的案例是将智能家居面板的UI资源从1.2MB压缩到380KB，同时保持60FPS的流畅动画效果。这种看似古老的编码格式，在资源受限的嵌入式领域依然焕发着强大生命力。