图像基础：像素、分辨率、通道、位深与图像存储格式

在进入 TinyML 图像预处理的具体操作之前，必须先建立对图像数据本身的清晰认知。TinyML 模型处理的不是“图片”，而是一组组数字——这些数字的组织方式、取值范围和排列顺序，直接决定了预处理管线的设计逻辑。本章将系统拆解像素、分辨率、通道、位深以及 RGB/灰度/BGR 等存储格式，帮助你理解为什么一张 96×96 的彩色图片在内存中占据 27,648 个字节，以及为什么在嵌入式部署时常常需要将 RGB 转为 BGR 或灰度图。

2.1 像素与分辨率：图像的最小单元与整体尺度

核心原理

像素（Pixel）是图像的最小采样单元，每个像素对应传感器感光阵列上的一个物理感光点。在数字图像中，像素不再具有物理尺寸，而是一个包含亮度或颜色信息的数值。分辨率则定义为图像在宽度和高度方向上的像素数量，通常写作 宽×高，例如 320×240。分辨率决定了图像的细节丰富程度，也直接决定了模型输入层的张量形状。

在 TinyML 场景中，分辨率的选择是一个关键权衡：分辨率越高，空间信息越丰富，但计算量和内存占用呈平方级增长。以 MobileNetV1 为例，输入从 224×224 降至 96×96，乘加运算量约减少至原来的 1/5.4，但精度可能下降 2~5 个百分点（具体取决于任务）。因此，实际部署时通常先确定任务所需的最低分辨率，再通过预处理中的 Resize 操作将原始图像调整到该尺寸。

判断方法与操作流程

• 查看传感器输出：OV2640 等摄像头模组通常支持多种分辨率输出，如 UXGA（1600×1200）、SVGA（800×600）、CIF（400×296）。在初始化时通过寄存器配置选择。
• 确定模型输入：从模型文件中读取输入张量的维度，例如 [1, 96, 96, 3] 表示批量 1、高 96、宽 96、通道 3。
• 匹配策略：若传感器分辨率大于模型输入，需 Resize 或裁剪；若小于，则需 Padding 或插值放大（但通常不推荐，因为会引入模糊）。

案例拆解：从 320×240 到 96×96 的 Resize 决策

假设我们使用 STM32F746 开发板（内置 320 KB RAM）和 OV2640 摄像头，目标是在 LCD 上实时显示并运行一个 96×96 输入的人脸检测模型。初始现象是：直接采集 320×240 RGB565 图像（约 150 KB），再软件缩放到 96×96，导致帧率仅 5 FPS，且内存紧张。

分析过程：软件缩放（双线性插值）在 MCU 上需要大量浮点运算，且 320×240 的中间缓冲区占用了近一半 RAM。优化方案是：将摄像头输出配置为 96×96 的 RGB565 模式（OV2640 支持硬件缩放），这样传感器直接输出目标分辨率，省去软件 Resize 步骤。实际操作中，通过 SCCB 协议写入寄存器 0xC0（RESET）、0xC1（SIZE）等配置，将输出尺寸锁定为 96×96。结果：帧率提升至 25 FPS，内存占用减少 80%。代价是丢失了原始高分辨率信息，但人脸检测任务在 96×96 下仍能达到 90% 以上的检出率。

常见误区

• 误区一：认为分辨率越高模型越准。实际上，超过模型训练时的输入分辨率，额外信息会被 Resize 丢弃，反而增加预处理耗时。
• 误区二：忽略传感器输出格式与模型输入格式的匹配。例如传感器输出 YUV422，而模型需要 RGB888，则需额外转换。
• 误区三：在 MCU 上使用浮点插值算法。应优先使用最近邻或定点整数插值，避免浮点库依赖。

2.2 通道与色彩空间：RGB、灰度与 BGR 的本质

核心原理

通道（Channel）是图像中每个像素所包含的独立数值维度。灰度图只有 1 个通道，数值代表亮度（0=黑，255=白）；彩色图通常有 3 个通道，RGB 分别代表红、绿、蓝三原色的强度。BGR 与 RGB 的唯一区别是通道存储顺序不同——OpenCV 等库默认使用 BGR，而大多数图像文件（如 PNG、JPEG 解码后）和深度学习框架（如 PyTorch 的 PIL 接口）使用 RGB。

在 TinyML 中，通道顺序错误是极其常见的 bug。例如，将 OpenCV 读取的 BGR 图像直接送入训练时使用 RGB 数据的模型，会导致颜色通道错位，模型精度急剧下降（通常表现为类似“色偏”的严重错误）。此外，灰度化可以显著减少计算量：3 通道彩色图的计算量是灰度图的约 3 倍（对于逐像素操作），但会丢失颜色信息，适用于不需要颜色区分的任务（如边缘检测、某些姿态估计）。

判断方法与转换流程

灰度转换的标准公式（ITU-R BT.601）为：

Gray = 0.299 × R + 0.587 × G + 0.114 × B

在定点 MCU 上，为避免浮点运算，通常使用整数近似：

Gray = (77 × R + 150 × G + 29 × B) >> 8

案例拆解：OpenCV 与 TensorFlow Lite 的通道顺序冲突

某工程师在 PC 上使用 OpenCV 读取图像并直接送入 TFLite 模型进行推理，发现准确率从训练时的 95% 骤降至 30%。初始现象是：所有预测结果偏向某一类别，且置信度极低。关键输入数据：模型训练时使用 PIL 加载 RGB 图像，而推理时使用 cv2.imread() 返回 BGR。分析判断：OpenCV 的 BGR 顺序导致模型接收到的“红色通道”实际是蓝色值，“蓝色通道”实际是红色值。由于模型在训练时学习的是 RGB 分布，输入 BGR 相当于对每个像素做了通道置换，破坏了特征分布。

实际操作步骤：在预处理代码中加入 cv2.cvtColor(img, cv2.COLOR_BGR2RGB)，或直接使用 img[:, :, ::-1] 反转通道。结果：准确率恢复至 94.5%。风险与代价：额外的通道反转操作耗时约 0.1ms（96×96 图像），几乎可忽略。复盘经验：在 TinyML 部署中，必须明确记录模型训练时的通道顺序，并在预处理管线中显式保证一致性，不能依赖“默认行为”。

常见误区

• 误区一：认为灰度图只是“黑白图”。实际上灰度有 256 个级别，并非二值图（只有 0 和 255）。
• 误区二：混淆 RGB565 与 RGB888。RGB565 用 5+6+5 位表示三通道，颜色精度较低，但节省内存，常用于 LCD 显示。
• 误区三：在归一化之前进行通道转换。应先完成通道顺序调整，再进行 Normalize，否则数值范围变化会影响转换精度。

2.3 位深与数据存储：从 8bit 到量化

核心原理

位深（Bit Depth）表示每个通道用多少位二进制数来存储一个像素值。最常见的 8bit 位深提供 256 个离散级别（0~255），而 16bit 提供 65536 个级别。位深决定了图像的动态范围，也直接影响内存占用和计算精度。在 TinyML 中，8bit 是主流，因为大多数 MCU 的 SIMD 指令（如 ARM Cortex-M 的 DSP 扩展）针对 8bit 整数优化，且 8bit 量化模型可以将权重和激活值压缩到原来的 1/4（相比 FP32）。

位深与模型量化的关系密切：训练时通常使用 FP32，推理时通过量化感知训练或后训练量化转为 INT8。预处理中的 Normalize 操作（如除以 255）本质上是将 8bit 整数映射到 [0,1] 浮点区间，而量化推理则直接使用整数运算，避免浮点转换开销。

操作流程与内存计算

1. 确定位深：传感器输出通常为 8bit 或 10bit（RAW 格式）。若为 10bit，需右移 2 位转为 8bit，或保留高 8 位。
2. 计算内存：图像字节数 = 宽 × 高 × 通道数 × (位深/8)。例如 96×96×3×1 = 27,648 字节。
3. 选择存储布局：HWC 布局在逐像素操作（如颜色转换）时更高效，因为同一像素的通道在内存中连续；CHW 布局在卷积运算时可能更高效（取决于硬件加速器）。

案例拆解：位深不匹配导致的图像异常

某智能门锁项目使用 OV5640 传感器输出 10bit RAW 数据，工程师直接将其作为 8bit 灰度图送入模型，结果图像整体偏暗且对比度极低。初始现象：模型检测率仅 60%。分析过程：10bit 数据范围 0~1023，直接截断为 8bit 时，仅保留了低 8 位（相当于取模 256），导致高亮度区域溢出为暗值。正确做法是取高 8 位（右移 2 位），或使用线性映射 out = in * 255 / 1023。实际操作：在传感器驱动中将数据右移 2 位，再存入缓冲区。结果：检测率恢复至 92%。复盘经验：位深处理必须在数据进入模型之前完成，且要明确传感器输出格式（RAW、YUV、RGB）与位深，不能想当然地认为“都是 8bit”。

常见误区

• 误区一：认为位深越高越好。在 TinyML 中，高位数增加内存和计算负担，且模型量化后精度提升有限。
• 误区二：忽略字节对齐。某些 DMA 和硬件加速器要求图像行宽按 4 字节对齐，否则访问越界。
• 误区三：在 Normalize 时使用浮点除法。应预先计算缩放因子（如 1/255）并转为定点乘法，避免每像素浮点运算。

2.4 图像存储格式与内存布局：HWC vs CHW

核心原理

图像在内存中的存储格式决定了数据如何被读取和访问。HWC（Height-Width-Channel）布局中，每个像素的通道值连续存储，例如 RGBRGBRGB...；CHW（Channel-Height-Width）布局中，所有像素的 R 通道连续存储，然后是 G 通道，最后是 B 通道。TinyML 框架的默认布局各不相同：TensorFlow Lite Micro 使用 HWC（与 TensorFlow 一致），ONNX Runtime 通常使用 CHW，CMSIS-NN 则要求 HWC 且通道数为 3 的倍数。

布局选择影响预处理效率：如果模型需要 CHW 而传感器输出 HWC，则需要在预处理中增加一次转置操作，这会消耗额外的 CPU 周期和内存带宽。在 MCU 上，转置操作可能比 Resize 更耗时，因此应尽量选择与模型输入一致的传感器输出格式，或使用硬件加速器支持的布局。

对比表：HWC 与 CHW 的工程权衡

操作流程：从传感器到模型输入的完整链路

1. 传感器配置：设置输出分辨率、格式（RGB565/RGB888/YUV）和帧率。
2. DMA 传输：将传感器数据直接搬运到 SRAM 缓冲区，避免 CPU 逐字节拷贝。
3. 格式转换：若需要，将 RGB565 转为 RGB888，或彩色转灰度。
4. 布局调整：若模型需要 CHW，则进行转置；否则保持 HWC。
5. 归一化：将像素值从 [0,255] 映射到模型要求的范围（如 [-1,1] 或 [0,1]）。

案例拆解：CMSIS-NN 的 HWC 约束

某开发者使用 STM32H743 的 CMSIS-NN 库部署图像分类模型，发现推理时间高达 120ms，远超预期。初始现象：CPU 占用率 100%，但性能不达标。分析过程：CMSIS-NN 的 arm_convolve_HWC_q7 函数要求输入为 HWC 布局且通道数 C 为 4 的倍数（内部使用 SIMD 优化）。而开发者从传感器获取的是 RGB888（C=3），导致库内部进行了填充和重排，增加了额外开销。实际操作：在预处理中将 RGB888 扩展为 RGBA（C=4），并调整通道顺序为 R-G-B-A（A 填充 0 或 255）。结果：推理时间降至 45ms，性能提升 2.7 倍。复盘经验：阅读硬件加速库的文档，了解其数据布局和通道对齐要求，是 TinyML 部署的关键步骤。

常见误区

• 误区一：认为所有模型都接受任意布局。实际上，模型转换工具会固化输入布局，运行时必须严格匹配。
• 误区二：忽略字节对齐。CMSIS-NN 要求行宽按 4 字节对齐，否则可能触发硬件异常。
• 误区三：在预处理中多次拷贝数据。应尽量使用指针操作和原地转换，减少内存带宽消耗。

2.5 综合复盘：图像基础在 TinyML 预处理中的核心地位

像素、分辨率、通道、位深和存储格式这五个概念构成了 TinyML 图像预处理的“数据契约”。任何预处理操作——Resize、Normalize、色彩转换——都必须基于对这些参数的精确理解。一个典型的错误链条是：传感器输出 10bit RAW → 错误截断为 8bit → 通道顺序未转换 → 模型输入布局不匹配 → 精度崩溃。每一个环节的错误都会累积，最终导致部署失败。

在实际项目中，建议在预处理模块的入口处增加一个“数据校验”步骤：打印或断言图像的宽度、高度、通道数、位深和布局，与模型输入要求进行比对。这虽然会增加少量代码，但能避免大量调试时间。同时，将预处理封装为独立的可测试模块，使用 PC 端 Python 脚本生成测试向量，在 MCU 上验证输出一致性，是保证正确性的有效手段。