EmbedPix 嵌图匠：把图片精确转成单片机要的格式
下载即用：BMP 1–32 位、PNG、JPG、RGB565 原始数据与可直接入固件的 C 数组，并提供大小端、RGB/BGR、扫描方向与行对齐控制。本地工具，无账号、无云端、无常驻进程。
EmbedPix 嵌图匠：把图片精确转成单片机要的格式
一句话：把「图片」精确转成「单片机真正需要的格式」——RGB565 裸数据、C 数组、1–32 位 BMP，带上大小端 / RGB-BGR / 扫描方向 / 行对齐控制。本地工具，不联网、不要账号。
📦 下载
| 平台 | 获取方式 |
|---|---|
| Windows x64 | Release 页下载安装包（约 3.3 MB）：https://github.com/Mamekokwai/EmbedPix/releases↗ |
| macOS / Linux | 从源码构建（CI 已覆盖三平台编译验证） |
从源码构建：
npm install
npm run tauri dev # 开发模式
npm run build # 构建前端需要本机装好对应平台的 Tauri 桌面运行环境（Rust 工具链 + 平台 WebView 依赖）。
当前限制（v0.1.4，早期版本）：
| 限制 | 值 |
|---|---|
| 输入文件大小 | ≤ 32 MB |
| 单边尺寸 | ≤ 8192 px |
| 总像素 | ≤ 16,777,216（约 4096×4096） |
🚀 快速上手
导入图片 → 预览 / 缩放 → 调尺寸与像素参数 → 导出- 导入：单张或多张（支持拖入替换已有图片），接受 PNG、JPEG/JPG、BMP、GIF、WEBP
- 预览：带缩放的实时预览，所见即所出
- 尺寸：可设输出宽高，支持保持比例锁定
- 输出位置：源文件目录 / 指定子目录 / 指定目录 / 覆盖原图 / 覆盖后删除源图
- C 数组：自定义数组名（自动过滤非法字符、避开 C 关键字冲突）
🧩 支持的输出格式
| 格式 | 位深 | 说明 |
|---|---|---|
| BMP | 1 / 4 / 8 / 16 / 24 / 32 位 | 仅 32 位保留透明度；≤8 位生成调色板，16 位写 BITFIELDS 掩码 |
| PNG | 24 / 32 位 | 24 位不含透明度；32 位保留透明度，适合无损资源 |
| JPG | 24 位（有损） | 质量可调（默认 85），不支持透明；透明区域用背景色合成 |
| RGB565 BIN | 16 位原始数据 | 直接喂给 MCU 屏幕的裸像素流 |
| C 数组 | RGB565 源码 | 可直接加入固件工程，无需文件系统 |
RGB565 的打包方式：
value = (r << 11) | (g << 5) | b; // 5 / 6 / 5⚙️ 四个关键参数：选错会怎样
这四个开关是 EmbedPix 相对通用转换工具的核心价值。
1. 字节序（小端 / 大端）
同一个 0xF800（纯红）在内存里是 00 F8 还是 F8 00，取决于你的屏幕控制器和 DMA 怎么读缓冲区。选错就是整屏颜色错乱，而且现象很容易被误判成「初始化序列写错了」。
2. 通道顺序（RGB / BGR）
大量 SPI 屏控制器（ST7789、ILI9341 这类）实际按 BGR 解释 16 位像素。很多人第一次点亮屏幕时看到的「红蓝互换」，根源就在这——而改代码里的位操作远不如导出时切一下干净。
3. 扫描方向（顶部朝下 / 底部朝上）
BMP 格式天生是底部朝上（bottom-up）存的，而多数屏幕按行从上往下刷。方向不对就是整图上下翻。这个参数让你不用在刷屏循环里写反向索引。
4. 行对齐（1 / 2 / 4 字节）
每行像素数据的补齐字节数。做 DMA 传输时，很多 MCU 要求传输起始地址和长度满足 4 字节对齐才能跑满带宽——行尾补齐 2 个字节，往往就是「偶发撕裂」和「稳定满速」的区别。
举个例子：320 像素宽的 RGB565 图，一行是 640 字节（已 4 字节对齐）；而 321 像素宽是 642 字节，需要补到 644 才对齐。这种账手算容易错，工具里选一下就好。
🛡️ 安全设计（不会悄悄给你坏文件）
嵌入式工具最怕「悄悄给你一个坏文件」，所以：
- 覆盖原图时，旧图先移入同目录的
bak文件夹，再把新文件写回原位 - 导出成功后删除源图片属于破坏性操作，启用时会弹确认
- 覆盖同名输出文件是独立开关，不勾选就不会动已有文件
- 导出失败必须给出可理解的错误，不允许静默生成格式错误的文件
另外还有批量水印：可配位置（四角）、不透明度、字号，加在导出的栅格图上。
🖥️ 应用本身
| 项 | 值 |
|---|---|
| 平台 | Windows / macOS / Linux |
| 界面 | 桌面三段骨架（标题栏 / 侧栏 / 主视图），侧栏可切图标或文字模式 |
| 窗口 | 默认 1100×760，最小 480×560，窄窗自动堆叠布局 |
| 语言 | 中文界面 |
| 账号 | 不需要，无云端、无遥测、无时间追踪 |
| 后台 | 无常驻进程——核心图像处理在 Rust 里按需执行 |
| 更新 | 内置检查更新：读 GitHub Release、校验 SHA-256 后下载，带进度反馈 |
| 许可 | MIT（开源） |
窗口最小尺寸下依然可访问、可滚动、可操作——UI 覆盖了 820 / 760 / 620 / 560 / 500px 五档断点，窄窗优先收窄侧栏而不隐藏功能。
以下是背景与技术实现（只想解决问题的可以到此为止）
它为什么存在
做嵌入式 UI 的人大概都遇过同一件事：图在 PS / Figma 里好好的，导出来喂给屏幕就是不对。
要 RGB565 的原始数据，绘图软件只能给你 PNG；要顶部朝下的扫描顺序，BMP 天生是从下往上存的；屏幕花屏了，查半天发现是 RGB 和 BGR 反了；DMA 传输要求 4 字节对齐，行尾少补两个字节就撕裂成斜的。最后只能临时写个 Python 脚本，或者找个在线转换网站——把工程图上传到别人服务器上。
| 痛点 | 常见做法 | EmbedPix |
|---|---|---|
| 要 RGB565 原始数据 | 手写脚本 / 在线转换 | 直接导出 RGB565 BIN |
| 要写进固件的 C 数组 | 用 xxd / 脚本拼 | 直接导出 .c 数组源码 |
| 需要 1/4/8 位 BMP（墨水屏、单色屏） | 绘图软件导不出 | BMP 1/4/8/16/24/32 位可选 |
| 屏幕颜色 RGB/BGR 反了 | 改代码里硬凑 | 导出时切 RGB / BGR |
| 大小端不匹配 | 手动字节交换 | 切 小端 / 大端 |
| 图像上下颠倒 | 改扫描方向代码 | 切 顶部朝下 / 底部朝上 |
| DMA 要求行对齐 | 手算补齐字节 | 行对齐 1 / 2 / 4 |
它不做「图像编辑」，只做格式正确这一件事——而这恰恰是嵌入式开发里最容易出错、最难排查的一环。
技术实现
如果你好奇它是怎么搭的：
| 层 | 技术 |
|---|---|
| 外壳 | Tauri 2（Rust）+ React 19 + TypeScript + Vite |
| 图像处理 | Rust image 0.24（png/jpeg/bmp/gif/webp） |
| 网络（更新） | reqwest + rustls，sha2 做摘要校验 |
| 对话框 | rfd |
| 编码实现 | 自行实现 BMP 位深/调色板/掩码、RGB565 打包、行对齐补齐、C 数组生成 |
| 构建 | GitHub Actions 三平台交叉验证（ubuntu / macos / windows） |
架构上有条清晰的分界：严格的格式编码、文件写入、平台对话框都放在 Rust；前端只负责 UI、交互状态和预览。Rust 侧的命令入口保持薄，图像处理逻辑按 feature 拆到独立模块（bmp.rs / raw.rs）。
源码目录也是按职责切的：src/app 壳层、src/features 功能、src/shared 稳定共享组件、src/platform 只放 Tauri 适配。
后续规划
作者列的路线：
- 图片体积压缩（把资源塞进更小的 Flash）
- GIF 生成与导出
- 简单的图片编辑：裁剪 / 旋转 / 镜像
明确不做的：账号系统、云端服务、时间追踪、SQLite，以及一切和图片处理无关的复杂功能。
小结
EmbedPix 的定位很窄但很准：它不跟 Photoshop 比修图，只解决「导出的二进制到底对不对」。
对嵌入式 UI 开发者来说，这恰好是最耗时的一块——那些 RGB/BGR、大小端、行对齐的问题，排查一次可能就是一个下午。把格式控制收进一个本地工具，比每次临时写脚本靠谱得多。
参考
- 项目仓库：https://github.com/Mamekokwai/EmbedPix↗
- Release 下载：https://github.com/Mamekokwai/EmbedPix/releases↗
- 许可：MIT · 作者：ZeroThrax
