多维数组与位图数据的转换

多维数组与位图数据的转换，听起来像是底层技术活，但说白了，就是同一堆像素在不同视角下的“身份切换”。位图本身是按行优先排列的二值或灰度像素序列，而像 NumPy 的 `ndarray` 这类多维数组，则用结构化维度来描述空间布局。转换不是简单的格式切换，而是理解同一像素集合的两种语言。

### 图像转位图数组（用于嵌入式显示） 最常见的场景，是把一张图片转成 OLED 或 LCD 屏幕直接吃的字节数组，比如 128×64 的单色屏。整个过程分四步走：尺寸适配 → 灰度化 → 二值化 → 按字节打包。 先缩放到目标分辨率，比如 `img.resize((128, 64))`，确保宽高和硬件对上。然后转灰度，再用阈值二值化：`np.array(img.convert("L")) > 128`，得到布尔矩阵。接下来，每 8 个像素合并成 1 个字节，高位在前——`np.packbits()` 自动搞定，输出形状变成 `(height, width//8)`。最后，如果需要 C 风格的十六进制数组（比如 `{0x01, 0xFF, ...}`），再用 `.tobytes().hex()` 拆分并格式化。这套流程在嵌入式开发中几乎算标准动作，但初学者常卡在“8 像素打包”这一步，其实核心就是按行把二进制位塞进字节。 ### 位图数组还原为多维数组 反过来，从嵌入式设备导出的一串字节（比如 bytes 或 list of int），要复原成可处理的数组，关键得先搞清楚原始布局。假设是单色 128×64 屏数据，按行存储、每字节 8 像素，那就先把数据转成 uint8 数组：`np.frombuffer(data, dtype=np.uint8)`。接着 reshape 成 `(64, 128//8)`，再用 `np.unpackbits()` 展开成 `(64, 128)` 的布尔数组。 这里有个重要提醒：位图数据本身不带调色信息。纯位图（BMP 文件头除外）不包含颜色模型，所以要还原成灰度或彩色，必须额外携带 palette 或通道说明——否则只能得到二值图像。这也是为什么很多嵌入式驱动手册里，会专门强调“数据按列/行顺序排列，每字节高位对应左侧像素”。 ### PyTorch/TensorFlow 输入所需的维度对齐 到了深度学习这块，框架对输入张量的轴顺序有硬性约定。PyTorch 要求 `[C, H, W]`，TensorFlow 则常用 `[H, W, C]`。用 PIL 加载图片默认是 `[H, W, C]`（RGB 为 3），转成 Tensor 后需要用 `.permute(2, 0, 1)` 调整。灰度图更简单：PIL 返回 `[H, W]`，得先 `.unsqueeze(0)` 补上通道维，变成 `[1, H, W]`。 批量数据堆叠时，确保所有样本 shape 一致是基本操作。如果原始数据是 `[N, H, W, C]`，而模型要 `[N, C, H, W]`，就用 `transpose(0, 3, 1, 2)` 或 `moveaxis` 搞定。注意，`a.reshape(3,4)` 只改形状不改变内存顺序，而 `a.transpose()` 是交换轴索引——两者效果完全不同，初学者容易混淆，乱用 reshape 会导致像素错位。 ### 避免常见陷阱 转换代码本身不难，容易出错的地方往往在语义理解上。 - **别把“位图”和“BMP 文件”混为一谈**：前者是像素的二值/灰度阵列，后者是带文件头、信息头、调色板的完整二进制格式。很多新手拿 `open()` 读 BMP 文件，却当纯位图处理，结果解析失败。 - **reshape 不等于 transpose**：这个前面提过，但值得再强调。`a.reshape(3,4)` 和 `a.transpose()` 在后续切片和广播行为上差异巨大，写代码前最好画个草图确认一下。 - **二值化阈值不是万能的**：全局阈值方法（比如直接 `> 128`）在光照均匀时还好，但遇到光照不均，细节会丢失。这时候得考虑局部自适应方法，比如 OpenCV 的 `cv2.adaptiveThreshold`，它能根据局部灰度动态计算阈值，效果稳定得多。 - **字节序与位序要统一**：OLED 驱动通常要求 MSB 在前，即第 0 像素对应最高位。NumPy 1.23+ 的 `np.packbits(..., bitorder='big')` 可以显式控制，旧版本则默认 MSB 在前（Linux）或 LSB 在前（某些平台），写跨平台代码时必须注意。 说到底，多维数组和位图数据的转换，本质上就是搞清楚“像素在内存里怎么排的”，然后对应地 `reshape`、`packbits` 或 `unpackbits`。理解了这一点，所有代码都会变得顺理成章。