Tasmota 中的 JPEGDEC面向 ESP32/ESP8266 的轻量级高性能 JPEG 解码库实战指南【免费下载链接】TasmotaAlternative firmware for ESP8266 and ESP32 based devices with easy configuration using webUI, OTA updates, automation using timers or rules, expandability and entirely local control over MQTT, HTTP, Serial or KNX. Full documentation at项目地址: https://gitcode.com/GitHub_Trending/ta/TasmotaJPEGDEC 是 BitBank Software作者 Larry Bank开发的一款专为内存受限 MCU 设计的 JPEG 解码库仅需约 20KB RAM 即可运行被 Tasmota 固件用于 Berry 脚本img模块的图像解码。本文以 JPEGDEC/README.md 为主线结合仓库内 JPEGDEC.h 头文件、examples 示例 以及 Tasmota 的 xdrv_52_3_berry_img.ino 集成代码系统讲解其架构、API、缩放/裁剪/抖动等进阶能力以及如何在嵌入式项目中直接落地使用。JPEGDEC 解码演示效果库的定位与设计初衷JPEGDEC 最初源于作者 Larry Bank 自 1989 年起积累的文档影像与图像处理库。作者在寻找适合 Arduino 的 JPEG 查看器时发现市面上的方案往往为了在几乎没有 RAM 的 MCU 上运行而牺牲速度。于是他决定从零重构自己的 JPEG 解码代码目标明确任何拥有至少 20KB RAM 的 MCU 都能运行作者实测过最简单的 Cortex-M0 也能正常工作。这段背景决定了 JPEGDEC 的核心设计哲学低内存占用解码状态机、Huffman 表、量化表与像素缓冲全部内置于JPEGIMAGE结构体见 JPEGDEC.h类实例本身约消耗 17.5KB RAM且内部不动态分配任何内存所有内存管理决策交由使用者这对 Tasmota 这类长期运行、内存紧张的固件环境尤为重要。可移植 C 核心承担解码主逻辑的 C 代码完全可移植、无外部依赖而 C 类JPEGDEC只是对它的轻量封装头文件同时暴露了纯 C 接口JPEG_openRAM、JPEG_decode等。速度优先作者在注释中强调这是一份为商业客户优化代码的样本包含大量独特优化解码瓶颈最终会落在把像素搬运到显示屏这一步因此库提供JPEG_USES_DMA选项配合 DMA SPI 提升输出吞吐。核心特性一览根据 README.md 的 Features 清单并对照源码验证该库具备以下能力特性说明源码佐证JPEGDisplay 辅助类简化在 bb_spi_lcd 系列屏上显示 JPEG只需loadJPEG()/getJPEGInfo()两个方法JPEGDisplay.h极低内存门槛支持 ≥20KB RAM 的任意 MCU类注释less than 22K of RAMJPEGDEC.h内置裁剪比 JPEGTRAN 更快的裁剪功能未裁剪部分不解码crop_area 示例数据源灵活JPEG 数据可来自内存RAM/FLASH、SD 卡或任意自定义媒体五回调接口设计见下文快速降采样1/2、1/4、1/8 缩放JPEG_SCALE_HALF/QUARTER/EIGHTH选项Exif 缩略图检测并解码 JPEG 内嵌的 Exif 缩略图JPEG_EXIF_THUMBNAIL选项Baseline 全面支持灰度或 YCbCr 的 Baseline Huffman 图像JPEG_MODE_BASELINEProgressive 缩略图对渐进式 JPEG 支持 DC-only 缩略图解码JPEG_MODE_PROGRESSIVESIMD 颜色转换ESP32-S3、Arm NEON、x86 SSE2 平台优化s3_simd_420.S 等汇编Floyd-Steinberg 抖动输出 1/2/4-bpp 灰度抖动适合电子墨水屏dithering 示例性能模型什么决定了解码速度README 明确给出影响性能的两个最关键因素压缩数据大小——解码时间与待解码数据量基本呈线性关系输出缩放选项——缩小输出意味着更少的像素计算。由此得出两条实用建议要获得最快解码速度应选择满足观感的最低图像质量质量越低压缩体积越小当必须使用过大图像时用缩放选项以较低分辨率显示而不是硬解全尺寸。README 中的性能图表见仓库内 perf.jpg直观展示了不同 MCU 配合不同缩放档位的表现差异。Tasmota 场景下这条规则直接对应摄像头 JPEG 帧解到小屏的常见需求优先让摄像头输出低分辨率/低质量帧再配合JPEG_SCALE_*二次降采样。架构核心五回调接口让解码逻辑与显示、文件 I/O 完全解耦是 JPEGDEC 能跨平台运行的关键。解码器只依赖以下回调原型见 JPEGDEC.htypedef int32_t (JPEG_READ_CALLBACK)(JPEGFILE *pFile, uint8_t *pBuf, int32_t iLen); // 读取数据 typedef int32_t (JPEG_SEEK_CALLBACK)(JPEGFILE *pFile, int32_t iPosition); // 定位 typedef int (JPEG_DRAW_CALLBACK)(JPEGDRAW *pDraw); // 输出像素块 typedef void * (JPEG_OPEN_CALLBACK)(const char *szFilename, int32_t *pFileSize); // 打开文件 typedef void (JPEG_CLOSE_CALLBACK)(void *pHandle); // 关闭文件最少只需实现 1 个回调当 JPEG 数据位于内存RAM 或 FLASH时只需提供draw回调即openRAM()/openFLASH()场景从 SD 卡读取需 5 个回调全实现open/close/read/seek/draw。JPEGDRAW结构体JPEGDEC.h把每个像素块的信息交给回调包含像素块左上角坐标x/y、尺寸iWidth/iHeight、位深iBpp、像素指针pPixels以及用户指针pUser。draw回调返回1继续解码返回0立即中止——这为解码到一半就够用的场景如只取画面一角提供了廉价的中断机制。哈佛架构下的 openRAM 与 openFLASHREADME 特别提醒ESP32、ESP8266 等哈佛架构 MCUFLASH 中的常量数据不能像普通 RAM 一样直接按指针读取必须区分openRAM()RAM 数据与openFLASH()FLASH 数据而基于 ARM Cortex-M 的 MCU 二者可互换。头文件中的memcpy_P/PROGMEM宏JPEGDEC.h正是为这种架构差异准备的。数据来源与图像转 C 预处理README 指出仓库 test_images 中的图片如 tulips.h、thumb_test.h已被转换为 C 源码每个字节写成0xAB形式可直接编译进程序并存入 FLASH。转换可用image_to_c工具或 Linux 传统工具xxd完成。关键要求在 JPEG 数据数组前必须加const及需要时PROGMEM修饰确保数据落在 FLASH 而非 RAM否则会白白吞噬宝贵的 SRAM。JPEGDEC API 详解JPEGDEC类的完整公开接口JPEGDEC.h可按用途分组打开/关闭openRAM(uint8_t *pData, int iDataSize, JPEG_DRAW_CALLBACK *pfnDraw)——从 RAM 解码openFLASH(const uint8_t *pData, int iDataSize, JPEG_DRAW_CALLBACK *pfnDraw)——从 FLASH 解码open(const char *szFilename, open/close/read/seek/draw 五回调)——从文件系统解码open(void *fHandle, int iDataSize, close/read/seek/draw 回调)——从已打开句柄解码close()——释放/复位解码状态解码执行decode(int x, int y, int iOptions)——在指定坐标解码iOptions组合解码选项decodeDither(...)——抖动模式解码见下文专节查询信息getWidth()/getHeight()——图像尺寸getBpp()——位深getOrientation()——EXIF 方向getSubSample()——色度子采样方式getJPEGType()——Baseline/ProgressivehasThumb()/getThumbWidth()/getThumbHeight()——内嵌缩略图信息getLastError()——错误码配置setPixelType(int)——输出像素格式setCropArea(x, y, w, h)——裁剪区域setUserPointer(void *p)——向回调传递自定义上下文setMaxOutputSize(int iMaxMCUs)——限制每次 draw 回调的最大 MCU 数setFramebuffer(void*)——指定输出帧缓冲输出像素格式setPixelType头文件中的Pixel types枚举JPEGDEC.h定义了 7 种输出格式默认小端 RGB565RGB565_LITTLE_ENDIAN / RGB565_BIG_ENDIAN / RGB8888 EIGHT_BIT_GRAYSCALE / FOUR_BIT_DITHERED / TWO_BIT_DITHERED / ONE_BIT_DITHEREDSPI LCD 通常要求大端 RGB565RGB565_BIG_ENDIANRGB8888 适合写回 RGB 帧缓冲Tasmota 中用于转换为 3 字节 RGB888灰度/抖动格式则面向单色屏与电子墨水屏。解码选项decode 的 iOptionsJPEG_AUTO_ROTATE1 按 EXIF 方向自动旋转 JPEG_SCALE_HALF2 1/2 降采样 JPEG_SCALE_QUARTER4 1/4 降采样 JPEG_SCALE_EIGHTH8 1/8 降采样 JPEG_LE_PIXELS16 输出小端像素 JPEG_EXIF_THUMBNAIL32 解码内嵌 Exif 缩略图 JPEG_LUMA_ONLY64 仅解码亮度分量灰度输出加速 JPEG_USES_DMA128 配合 DMA 输出这些选项可用|组合例如decode(0, 0, JPEG_SCALE_QUARTER | JPEG_EXIF_THUMBNAIL)。错误码getLastError()返回的错误枚举JPEGDEC.hJPEG_SUCCESS0、JPEG_INVALID_PARAMETER、JPEG_DECODE_ERROR、JPEG_UNSUPPORTED_FEATURE、JPEG_INVALID_FILE、JPEG_ERROR_MEMORY。缩放为小屏省掉大量解码时间降采样在解码链路上直接生效而不是先解全图再抽点。结合 README 的性能说明解码时间的降幅大致随缩放档位线性下降。示例 esp32_jpeg.ino 中一张 12 兆像素照片内嵌的 320×240 缩略图以JPEG_SCALE_QUARTER解码MCU 实际只有 4×4 像素draw 回调收到的也自然是缩小后的像素块。裁剪跳过无用区域的快速裁剪README 宣称其内置裁剪比 JPEGTRAN 更快原理见 crop_area 示例未裁剪区域不参与解码。需要理解的两个要点MCU 边界对齐JPEG 由 8×8 像素块组成色度子采样后 MCU 可能是 16×8、8×16 或 16×16。因此setCropArea()会自动把请求区域对齐到 MCU 边界getCropArea()返回实际生效的区域保证调用方精确知道将得到什么draw 回调只收到裁剪内容JPEGDraw()回调仅被传入裁剪后的图像getWidth()仍返回全图尺寸绘制定位时应使用getCropArea()返回的裁剪宽高来计算居中偏移。Exif 缩略图照片的快速预览手机等设备拍摄的照片通常内嵌一张小型 Exif 缩略图。JPEG_EXIF_THUMBNAIL选项让解码器直接定位并解码缩略图而无需也无法快速解出全尺寸照片。结合JPEG_LUMA_ONLY之类选项可以在极低资源消耗下实现图库缩略图浏览。JPEGIMAGE结构体中的iThumbWidth/iThumbHeight/iThumbDataJPEGDEC.h记录了缩略图元数据。Floyd-Steinberg 抖动驱动电子墨水屏README 重点介绍了 1/2/4-bpp 灰度抖动的价值用误差扩散算法消除色块边界与重复花纹适合高分辨率电子墨水屏——README 中的演示图squirrel_dither.jpg即从 800×600 彩色 JPEG 解码为 2-bpp4 级灰度渲染到 400×300 的 4.2 英寸墨水屏。使用方式见 dithering.inojpg.setPixelType(ONE_BIT_DITHERED); // 或 FOUR_BIT_DITHERED uint8_t *pDither (uint8_t *)malloc(w * 16); // 需要额外缓冲图像宽 × 16 行 jpg.decodeDither(xoff, yoff, pDither, 0); free(pDither);注意两点抖动缓冲必须由调用方提供因为 Floyd-Steinberg 需要跨 MCU 边界扩散误差缓冲区至少要覆盖图像宽度 × 16 行若将误差限制在 MCU 块内块边界会产生可见条纹。1-bpp 输出中每字节 8 个像素MSB 为最左像素0黑 1白4-bpp 输出中每字节 2 个像素高半字节为左像素0黑 0xf白。SIMD 加速ESP32-S3 的硬件加成颜色转换YCbCr→RGB是解码热点。仓库源码中的 s3_simd_420.S、s3_simd_444.S、s3_simd_dequant.S 是 ESP32-S3 的 SIMD 汇编实现对应 README 所述ESP32-S3、Arm NEON、x86 SSE2三套 SIMD 颜色转换路径。为保证 SIMD 对齐JPEGIMAGE中的像素缓冲usPixels与 MCU 缓冲sMCUs均要求 16 字节对齐JPEGDEC.h这也是库内部保留8元素余量的原因。在 Tasmota 中的真实集成Berry img 模块Tasmota 通过 xdrv_52_3_berry_img.ino 将 JPEGDEC 封装进 Berry 脚本语言的img模块条件编译宏USE_BERRYUSE_BERRY_IMAGE。该文件的实现可以看作 JPEGDEC API 的官方级使用范本图像句柄image_t结构体持有JPEGDEC *jpeg实例L34-L42解码主流程jpeg_decode_one_image()L310-L347JPEGDEC *jpeg new JPEGDEC(); int result jpeg-openRAM(input_buf, len, jpeg_draw_mcu); jpeg-setUserPointer(ctx); // 通过 pUser 传入裁剪/步长上下文 jpeg-setPixelType(type); // EIGHT_BIT_GRAYSCALE / RGB565 / RGB8888 bool ok jpeg-decode(0, 0, 0); jpeg-close(); delete jpeg;draw 回调jpeg_draw_mcu()L241-L299从pDraw-pUser取回上下文处理源图尺寸与目标尺寸不一致时的顶部/左对齐裁剪跳过越界 MCU、截断边缘不完整 MCU并演示了 RGB8888→RGB888 的逐像素转换JPEG 头解析jpeg_size()L357-L395校验0xFFD8SOI 与0xFFD9EOI 标记扫描0xFFC0/0xFFC2SOF 段提取宽高——说明集成方甚至不依赖库就能预判图像尺寸。这一集成案例证明JPEGDEC 的类回调设计能干净地嵌入第三方固件且pUser指针机制天然适合把解码结果直接写入预分配帧缓冲。一个完整的解码示例以 esp32_jpeg.ino 为骨架展示FLASH 中存图 → 解码 → DMA 推送到 LCD的完整链路#include bb_spi_lcd.h #include JPEGDEC.h #include ../test_images/thumb_test.h // 已转为 C 数组的 JPEG JPEGDEC jpeg; BB_SPI_LCD lcd; // draw 回调把每个像素块写入 LCD 窗口可用 DMA 加速 int drawMCUs(JPEGDRAW *pDraw) { int iCount pDraw-iWidth * pDraw-iHeight; lcd.setAddrWindow(pDraw-x, pDraw-y, pDraw-iWidth, pDraw-iHeight); lcd.pushPixels(pDraw-pPixels, iCount, DRAW_TO_LCD | DRAW_WITH_DMA); return 1; // 返回 0 可提前终止解码 } void setup() { Serial.begin(115200); lcd.begin(DISPLAY_M5STACK_CORE2); if (jpeg.openFLASH((uint8_t *)thumb_test, sizeof(thumb_test), drawMCUs)) { Serial.printf(Image: %d x %d, orientation: %d, bpp: %d\n, jpeg.getWidth(), jpeg.getHeight(), jpeg.getOrientation(), jpeg.getBpp()); if (jpeg.hasThumb()) Serial.printf(Thumbnail: %d x %d\n, jpeg.getThumbWidth(), jpeg.getThumbHeight()); jpeg.setPixelType(RGB565_BIG_ENDIAN); // SPI LCD 需要大端 16 位像素 unsigned long t micros(); if (jpeg.decode(120, 100, JPEG_SCALE_QUARTER | JPEG_EXIF_THUMBNAIL)) Serial.printf(Decoded in %lu us\n, micros() - t); jpeg.close(); } }实用建议与注意事项内存规划类实例本身约 17.5KB RAM 且内部零动态分配适合 Arduino/ESP32 的栈上或全局静态实例抖动模式需自行额外提供宽×16字节缓冲哈佛架构选对入口ESP8266/ESP32 上 FLASH 数据务必走openFLASH()性能三原则优先降低图像压缩体积 → 必要时用JPEG_SCALE_*降采样 → 输出侧配合JPEG_USES_DMA与 DMA SPI裁剪先对齐setCropArea()会自动对齐 MCU 边界务必用getCropArea()的返回值计算实际绘制区域能力边界完整支持 Baseline Huffman灰度/YCbCrProgressive JPEG 仅支持 DC-only 缩略图解码JPEG_LUMA_ONLY适合仅需亮度信息的应用。JPEGDEC 以极低内存 高解码效率 全回调解耦三者的平衡成为 MCU 上 JPEG 解码的务实之选。无论是直接驱动 SPI LCD、驱动电子墨水屏还是像 Tasmota 那样作为 Berry 脚本的图像底层其 API 都保持了高度一致的调用模式打开数据源 → 设置像素类型与选项 → 在回调中消费像素块。【免费下载链接】TasmotaAlternative firmware for ESP8266 and ESP32 based devices with easy configuration using webUI, OTA updates, automation using timers or rules, expandability and entirely local control over MQTT, HTTP, Serial or KNX. Full documentation at项目地址: https://gitcode.com/GitHub_Trending/ta/Tasmota创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Tasmota 中的 JPEGDEC面向 ESP32/ESP8266 的轻量级高性能 JPEG 解码库实战指南【免费下载链接】TasmotaAlternative firmware for ESP8266 and ESP32 based devices with easy configuration using webUI, OTA updates, automation using timers or rules, expandability and entirely local control over MQTT, HTTP, Serial or KNX. Full documentation at项目地址: https://gitcode.com/GitHub_Trending/ta/TasmotaJPEGDEC 是 BitBank Software作者 Larry Bank开发的一款专为内存受限 MCU 设计的 JPEG 解码库仅需约 20KB RAM 即可运行被 Tasmota 固件用于 Berry 脚本img模块的图像解码。本文以 JPEGDEC/README.md 为主线结合仓库内 JPEGDEC.h 头文件、examples 示例 以及 Tasmota 的 xdrv_52_3_berry_img.ino 集成代码系统讲解其架构、API、缩放/裁剪/抖动等进阶能力以及如何在嵌入式项目中直接落地使用。JPEGDEC 解码演示效果库的定位与设计初衷JPEGDEC 最初源于作者 Larry Bank 自 1989 年起积累的文档影像与图像处理库。作者在寻找适合 Arduino 的 JPEG 查看器时发现市面上的方案往往为了在几乎没有 RAM 的 MCU 上运行而牺牲速度。于是他决定从零重构自己的 JPEG 解码代码目标明确任何拥有至少 20KB RAM 的 MCU 都能运行作者实测过最简单的 Cortex-M0 也能正常工作。这段背景决定了 JPEGDEC 的核心设计哲学低内存占用解码状态机、Huffman 表、量化表与像素缓冲全部内置于JPEGIMAGE结构体见 JPEGDEC.h类实例本身约消耗 17.5KB RAM且内部不动态分配任何内存所有内存管理决策交由使用者这对 Tasmota 这类长期运行、内存紧张的固件环境尤为重要。可移植 C 核心承担解码主逻辑的 C 代码完全可移植、无外部依赖而 C 类JPEGDEC只是对它的轻量封装头文件同时暴露了纯 C 接口JPEG_openRAM、JPEG_decode等。速度优先作者在注释中强调这是一份为商业客户优化代码的样本包含大量独特优化解码瓶颈最终会落在把像素搬运到显示屏这一步因此库提供JPEG_USES_DMA选项配合 DMA SPI 提升输出吞吐。核心特性一览根据 README.md 的 Features 清单并对照源码验证该库具备以下能力特性说明源码佐证JPEGDisplay 辅助类简化在 bb_spi_lcd 系列屏上显示 JPEG只需loadJPEG()/getJPEGInfo()两个方法JPEGDisplay.h极低内存门槛支持 ≥20KB RAM 的任意 MCU类注释less than 22K of RAMJPEGDEC.h内置裁剪比 JPEGTRAN 更快的裁剪功能未裁剪部分不解码crop_area 示例数据源灵活JPEG 数据可来自内存RAM/FLASH、SD 卡或任意自定义媒体五回调接口设计见下文快速降采样1/2、1/4、1/8 缩放JPEG_SCALE_HALF/QUARTER/EIGHTH选项Exif 缩略图检测并解码 JPEG 内嵌的 Exif 缩略图JPEG_EXIF_THUMBNAIL选项Baseline 全面支持灰度或 YCbCr 的 Baseline Huffman 图像JPEG_MODE_BASELINEProgressive 缩略图对渐进式 JPEG 支持 DC-only 缩略图解码JPEG_MODE_PROGRESSIVESIMD 颜色转换ESP32-S3、Arm NEON、x86 SSE2 平台优化s3_simd_420.S 等汇编Floyd-Steinberg 抖动输出 1/2/4-bpp 灰度抖动适合电子墨水屏dithering 示例性能模型什么决定了解码速度README 明确给出影响性能的两个最关键因素压缩数据大小——解码时间与待解码数据量基本呈线性关系输出缩放选项——缩小输出意味着更少的像素计算。由此得出两条实用建议要获得最快解码速度应选择满足观感的最低图像质量质量越低压缩体积越小当必须使用过大图像时用缩放选项以较低分辨率显示而不是硬解全尺寸。README 中的性能图表见仓库内 perf.jpg直观展示了不同 MCU 配合不同缩放档位的表现差异。Tasmota 场景下这条规则直接对应摄像头 JPEG 帧解到小屏的常见需求优先让摄像头输出低分辨率/低质量帧再配合JPEG_SCALE_*二次降采样。架构核心五回调接口让解码逻辑与显示、文件 I/O 完全解耦是 JPEGDEC 能跨平台运行的关键。解码器只依赖以下回调原型见 JPEGDEC.htypedef int32_t (JPEG_READ_CALLBACK)(JPEGFILE *pFile, uint8_t *pBuf, int32_t iLen); // 读取数据 typedef int32_t (JPEG_SEEK_CALLBACK)(JPEGFILE *pFile, int32_t iPosition); // 定位 typedef int (JPEG_DRAW_CALLBACK)(JPEGDRAW *pDraw); // 输出像素块 typedef void * (JPEG_OPEN_CALLBACK)(const char *szFilename, int32_t *pFileSize); // 打开文件 typedef void (JPEG_CLOSE_CALLBACK)(void *pHandle); // 关闭文件最少只需实现 1 个回调当 JPEG 数据位于内存RAM 或 FLASH时只需提供draw回调即openRAM()/openFLASH()场景从 SD 卡读取需 5 个回调全实现open/close/read/seek/draw。JPEGDRAW结构体JPEGDEC.h把每个像素块的信息交给回调包含像素块左上角坐标x/y、尺寸iWidth/iHeight、位深iBpp、像素指针pPixels以及用户指针pUser。draw回调返回1继续解码返回0立即中止——这为解码到一半就够用的场景如只取画面一角提供了廉价的中断机制。哈佛架构下的 openRAM 与 openFLASHREADME 特别提醒ESP32、ESP8266 等哈佛架构 MCUFLASH 中的常量数据不能像普通 RAM 一样直接按指针读取必须区分openRAM()RAM 数据与openFLASH()FLASH 数据而基于 ARM Cortex-M 的 MCU 二者可互换。头文件中的memcpy_P/PROGMEM宏JPEGDEC.h正是为这种架构差异准备的。数据来源与图像转 C 预处理README 指出仓库 test_images 中的图片如 tulips.h、thumb_test.h已被转换为 C 源码每个字节写成0xAB形式可直接编译进程序并存入 FLASH。转换可用image_to_c工具或 Linux 传统工具xxd完成。关键要求在 JPEG 数据数组前必须加const及需要时PROGMEM修饰确保数据落在 FLASH 而非 RAM否则会白白吞噬宝贵的 SRAM。JPEGDEC API 详解JPEGDEC类的完整公开接口JPEGDEC.h可按用途分组打开/关闭openRAM(uint8_t *pData, int iDataSize, JPEG_DRAW_CALLBACK *pfnDraw)——从 RAM 解码openFLASH(const uint8_t *pData, int iDataSize, JPEG_DRAW_CALLBACK *pfnDraw)——从 FLASH 解码open(const char *szFilename, open/close/read/seek/draw 五回调)——从文件系统解码open(void *fHandle, int iDataSize, close/read/seek/draw 回调)——从已打开句柄解码close()——释放/复位解码状态解码执行decode(int x, int y, int iOptions)——在指定坐标解码iOptions组合解码选项decodeDither(...)——抖动模式解码见下文专节查询信息getWidth()/getHeight()——图像尺寸getBpp()——位深getOrientation()——EXIF 方向getSubSample()——色度子采样方式getJPEGType()——Baseline/ProgressivehasThumb()/getThumbWidth()/getThumbHeight()——内嵌缩略图信息getLastError()——错误码配置setPixelType(int)——输出像素格式setCropArea(x, y, w, h)——裁剪区域setUserPointer(void *p)——向回调传递自定义上下文setMaxOutputSize(int iMaxMCUs)——限制每次 draw 回调的最大 MCU 数setFramebuffer(void*)——指定输出帧缓冲输出像素格式setPixelType头文件中的Pixel types枚举JPEGDEC.h定义了 7 种输出格式默认小端 RGB565RGB565_LITTLE_ENDIAN / RGB565_BIG_ENDIAN / RGB8888 EIGHT_BIT_GRAYSCALE / FOUR_BIT_DITHERED / TWO_BIT_DITHERED / ONE_BIT_DITHEREDSPI LCD 通常要求大端 RGB565RGB565_BIG_ENDIANRGB8888 适合写回 RGB 帧缓冲Tasmota 中用于转换为 3 字节 RGB888灰度/抖动格式则面向单色屏与电子墨水屏。解码选项decode 的 iOptionsJPEG_AUTO_ROTATE1 按 EXIF 方向自动旋转 JPEG_SCALE_HALF2 1/2 降采样 JPEG_SCALE_QUARTER4 1/4 降采样 JPEG_SCALE_EIGHTH8 1/8 降采样 JPEG_LE_PIXELS16 输出小端像素 JPEG_EXIF_THUMBNAIL32 解码内嵌 Exif 缩略图 JPEG_LUMA_ONLY64 仅解码亮度分量灰度输出加速 JPEG_USES_DMA128 配合 DMA 输出这些选项可用|组合例如decode(0, 0, JPEG_SCALE_QUARTER | JPEG_EXIF_THUMBNAIL)。错误码getLastError()返回的错误枚举JPEGDEC.hJPEG_SUCCESS0、JPEG_INVALID_PARAMETER、JPEG_DECODE_ERROR、JPEG_UNSUPPORTED_FEATURE、JPEG_INVALID_FILE、JPEG_ERROR_MEMORY。缩放为小屏省掉大量解码时间降采样在解码链路上直接生效而不是先解全图再抽点。结合 README 的性能说明解码时间的降幅大致随缩放档位线性下降。示例 esp32_jpeg.ino 中一张 12 兆像素照片内嵌的 320×240 缩略图以JPEG_SCALE_QUARTER解码MCU 实际只有 4×4 像素draw 回调收到的也自然是缩小后的像素块。裁剪跳过无用区域的快速裁剪README 宣称其内置裁剪比 JPEGTRAN 更快原理见 crop_area 示例未裁剪区域不参与解码。需要理解的两个要点MCU 边界对齐JPEG 由 8×8 像素块组成色度子采样后 MCU 可能是 16×8、8×16 或 16×16。因此setCropArea()会自动把请求区域对齐到 MCU 边界getCropArea()返回实际生效的区域保证调用方精确知道将得到什么draw 回调只收到裁剪内容JPEGDraw()回调仅被传入裁剪后的图像getWidth()仍返回全图尺寸绘制定位时应使用getCropArea()返回的裁剪宽高来计算居中偏移。Exif 缩略图照片的快速预览手机等设备拍摄的照片通常内嵌一张小型 Exif 缩略图。JPEG_EXIF_THUMBNAIL选项让解码器直接定位并解码缩略图而无需也无法快速解出全尺寸照片。结合JPEG_LUMA_ONLY之类选项可以在极低资源消耗下实现图库缩略图浏览。JPEGIMAGE结构体中的iThumbWidth/iThumbHeight/iThumbDataJPEGDEC.h记录了缩略图元数据。Floyd-Steinberg 抖动驱动电子墨水屏README 重点介绍了 1/2/4-bpp 灰度抖动的价值用误差扩散算法消除色块边界与重复花纹适合高分辨率电子墨水屏——README 中的演示图squirrel_dither.jpg即从 800×600 彩色 JPEG 解码为 2-bpp4 级灰度渲染到 400×300 的 4.2 英寸墨水屏。使用方式见 dithering.inojpg.setPixelType(ONE_BIT_DITHERED); // 或 FOUR_BIT_DITHERED uint8_t *pDither (uint8_t *)malloc(w * 16); // 需要额外缓冲图像宽 × 16 行 jpg.decodeDither(xoff, yoff, pDither, 0); free(pDither);注意两点抖动缓冲必须由调用方提供因为 Floyd-Steinberg 需要跨 MCU 边界扩散误差缓冲区至少要覆盖图像宽度 × 16 行若将误差限制在 MCU 块内块边界会产生可见条纹。1-bpp 输出中每字节 8 个像素MSB 为最左像素0黑 1白4-bpp 输出中每字节 2 个像素高半字节为左像素0黑 0xf白。SIMD 加速ESP32-S3 的硬件加成颜色转换YCbCr→RGB是解码热点。仓库源码中的 s3_simd_420.S、s3_simd_444.S、s3_simd_dequant.S 是 ESP32-S3 的 SIMD 汇编实现对应 README 所述ESP32-S3、Arm NEON、x86 SSE2三套 SIMD 颜色转换路径。为保证 SIMD 对齐JPEGIMAGE中的像素缓冲usPixels与 MCU 缓冲sMCUs均要求 16 字节对齐JPEGDEC.h这也是库内部保留8元素余量的原因。在 Tasmota 中的真实集成Berry img 模块Tasmota 通过 xdrv_52_3_berry_img.ino 将 JPEGDEC 封装进 Berry 脚本语言的img模块条件编译宏USE_BERRYUSE_BERRY_IMAGE。该文件的实现可以看作 JPEGDEC API 的官方级使用范本图像句柄image_t结构体持有JPEGDEC *jpeg实例L34-L42解码主流程jpeg_decode_one_image()L310-L347JPEGDEC *jpeg new JPEGDEC(); int result jpeg-openRAM(input_buf, len, jpeg_draw_mcu); jpeg-setUserPointer(ctx); // 通过 pUser 传入裁剪/步长上下文 jpeg-setPixelType(type); // EIGHT_BIT_GRAYSCALE / RGB565 / RGB8888 bool ok jpeg-decode(0, 0, 0); jpeg-close(); delete jpeg;draw 回调jpeg_draw_mcu()L241-L299从pDraw-pUser取回上下文处理源图尺寸与目标尺寸不一致时的顶部/左对齐裁剪跳过越界 MCU、截断边缘不完整 MCU并演示了 RGB8888→RGB888 的逐像素转换JPEG 头解析jpeg_size()L357-L395校验0xFFD8SOI 与0xFFD9EOI 标记扫描0xFFC0/0xFFC2SOF 段提取宽高——说明集成方甚至不依赖库就能预判图像尺寸。这一集成案例证明JPEGDEC 的类回调设计能干净地嵌入第三方固件且pUser指针机制天然适合把解码结果直接写入预分配帧缓冲。一个完整的解码示例以 esp32_jpeg.ino 为骨架展示FLASH 中存图 → 解码 → DMA 推送到 LCD的完整链路#include bb_spi_lcd.h #include JPEGDEC.h #include ../test_images/thumb_test.h // 已转为 C 数组的 JPEG JPEGDEC jpeg; BB_SPI_LCD lcd; // draw 回调把每个像素块写入 LCD 窗口可用 DMA 加速 int drawMCUs(JPEGDRAW *pDraw) { int iCount pDraw-iWidth * pDraw-iHeight; lcd.setAddrWindow(pDraw-x, pDraw-y, pDraw-iWidth, pDraw-iHeight); lcd.pushPixels(pDraw-pPixels, iCount, DRAW_TO_LCD | DRAW_WITH_DMA); return 1; // 返回 0 可提前终止解码 } void setup() { Serial.begin(115200); lcd.begin(DISPLAY_M5STACK_CORE2); if (jpeg.openFLASH((uint8_t *)thumb_test, sizeof(thumb_test), drawMCUs)) { Serial.printf(Image: %d x %d, orientation: %d, bpp: %d\n, jpeg.getWidth(), jpeg.getHeight(), jpeg.getOrientation(), jpeg.getBpp()); if (jpeg.hasThumb()) Serial.printf(Thumbnail: %d x %d\n, jpeg.getThumbWidth(), jpeg.getThumbHeight()); jpeg.setPixelType(RGB565_BIG_ENDIAN); // SPI LCD 需要大端 16 位像素 unsigned long t micros(); if (jpeg.decode(120, 100, JPEG_SCALE_QUARTER | JPEG_EXIF_THUMBNAIL)) Serial.printf(Decoded in %lu us\n, micros() - t); jpeg.close(); } }实用建议与注意事项内存规划类实例本身约 17.5KB RAM 且内部零动态分配适合 Arduino/ESP32 的栈上或全局静态实例抖动模式需自行额外提供宽×16字节缓冲哈佛架构选对入口ESP8266/ESP32 上 FLASH 数据务必走openFLASH()性能三原则优先降低图像压缩体积 → 必要时用JPEG_SCALE_*降采样 → 输出侧配合JPEG_USES_DMA与 DMA SPI裁剪先对齐setCropArea()会自动对齐 MCU 边界务必用getCropArea()的返回值计算实际绘制区域能力边界完整支持 Baseline Huffman灰度/YCbCrProgressive JPEG 仅支持 DC-only 缩略图解码JPEG_LUMA_ONLY适合仅需亮度信息的应用。JPEGDEC 以极低内存 高解码效率 全回调解耦三者的平衡成为 MCU 上 JPEG 解码的务实之选。无论是直接驱动 SPI LCD、驱动电子墨水屏还是像 Tasmota 那样作为 Berry 脚本的图像底层其 API 都保持了高度一致的调用模式打开数据源 → 设置像素类型与选项 → 在回调中消费像素块。【免费下载链接】TasmotaAlternative firmware for ESP8266 and ESP32 based devices with easy configuration using webUI, OTA updates, automation using timers or rules, expandability and entirely local control over MQTT, HTTP, Serial or KNX. Full documentation at项目地址: https://gitcode.com/GitHub_Trending/ta/Tasmota创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
