简介这是一个基于libjpeg的YUV转JPEG示例工程面向图像处理、视频编码方向的开发者演示如何借助libjpeg库将YUV色彩空间数据编码为JPEG文件。压缩包内共8个文件包含1个C源文件yuvtojpeg.c、4个头文件jpeglib.h、jconfig.h、jerror.h、jmorecfg.h、2个静态库libjpeg.a和1个libjpeg.la库文件整体仅463KB结构紧凑适合作为轻量级参考工程。源码详细展示了初始化压缩结构、设置输出目标、YUV到RGB转换、jpeg_write_scanlines逐行写入、结束编码并释放资源等关键流程可帮助读者快速理解libjpeg的API调用顺序与JPEG编码原理。同时资源中的静态库与头文件已配套齐全能够直接用于编译测试免去自行构建依赖的麻烦。目前已有1226人学习下载适合需要在实际项目中实现YUV转JPG功能或正在学习图像编码原理的开发人员参考复用。 搞视频处理的人十有八九都遇到过这个场景手里拿到一个几百MB的.yuv文件双击打不开Windows自带的图片查看器完全不认识网上搜“yuv 打开”翻半天下了几个播放器还是花屏。说白了YUV是摄像头、编解码器最常用的原始图像格式它没有文件头、没有宽高信息就是一堆裸数据普通看图软件根本不知道该怎么解析。这篇文章要聊的就是基于libjpeg库把YUV数据编码成JPG图片的一套完整方案。我会从格式原理讲到代码实现再补上我实际调试中踩过的坑适合正在做视频采集、图像处理或者单纯被.yuv文件折磨得头疼的同学参考。1. 项目背景为什么会有“YUV转JPG”这种需求1.1 从打不开的.yuv文件说起很多人第一次接触YUV不是因为在做视频开发而是因为拿到了一个后缀是.yuv的文件。这个文件可能来自某个视频采集设备、某段摄像头测试视频或者某个聊天工具缓存出来的原始数据。Windows下没有默认的YUV打开软件因为这个格式本身就不是给人直接看的——它是给程序用的中间数据。YUV和RGB一样都是描述颜色的方式。区别在于RGB把颜色拆成红绿蓝三个分量每个像素都要存三个值而YUV把亮度Y和颜色U、V分开存储。人眼对亮度敏感、对颜色不敏感所以视频编码领域几乎都是先把RGB转成YUV再对色度分量做压缩采样这样可以省掉大量存储和带宽。摄像头采集出来的原始数据、H.264编码器的输入输出很多都是YUV格式。这就带来一个现实问题视频做完了、采集程序写完了你总得看一眼效果吧总得截个图发给同事确认吧YUV不能直接预览最简单的办法就是把它转成JPG。JPG是通用格式任何设备、任何软件都能打开传输也方便。所以“YUV转JPG”这个需求几乎是所有做视频图像相关开发的人绕不过去的一道坎。1.2 为什么选择libjpeg作为编码核心把YUV转成JPG方案其实有好几种。最省事的方案是直接调OpenCV的imwrite函数但它内部用的是自己的编码器而且依赖整个OpenCV库就为一个编码功能引进来一个大块头有点不划算。还有一种方案是走FFmpeg功能确实强大但配置复杂而且为了一个简单的格式转换去拉整个FFmpeg学习和工程成本偏高。libjpeg就不一样了它是专门做JPEG编码解码的C语言库轻量、稳定、可移植性极强从单片机到服务器都能跑。它只负责JPEG这一件事我们只需要自己处理YUV到RGB的转换然后把RGB数据交给libjpeg按行编码就行。这种“自己控制颜色转换、用libjpeg专注编码”的分工方式逻辑清晰不管是嵌入式开发还是桌面应用都适用没有任何多余的依赖踩坑也少。2. 核心原理YUV和libjpeg是怎么配合的2.1 YUV420的采样布局搞错一个像素就全乱套在动手写代码之前必须把YUV的内存布局搞清楚。最常见的YUV格式是YUV420也叫I420它采用4:2:0色度采样每4个亮度像素共享一组色度像素。也就是说Y分量是一个wh的平面U分量是(w/2)(h/2)的平面V分量也是(w/2)*(h/2)的平面三个平面依次排列在内存里。用数据说话。一张1280x720的YUV420图片Y分量有1280x720921600个字节U和V分量各是640x360230400个字节。整个文件大小就是9216002304002304001382400字节。如果你手里的.yuv文件大小刚好等于这个值那它基本就是YUV420格式如果不是那可能是YUV422、YUV444或者是加了文件头需要另做处理。这里有一个新手最容易踩的坑YUV420的U、V平面只有宽高的一半但很多人在代码里习惯性用w*h去遍历结果越界读取读出来的颜色数据完全是垃圾值最后编码出来的图片要么绿油油的要么花屏。做转换之前第一件事就是确认输入YUV的格式和宽高再用验证文件大小的方式来反推格式这一步能省掉后面大量排查时间。2.2 YUV转RGB的换算公式和色彩空间选择libjpeg不认识YUV它默认的输入色彩空间是RGB所以我们得先把YUV转成RGB。这个转换公式很多人手写时有细微差别不同亮度范围full range还是limited range公式还不一样我在这里给出最常用的一套标准定义BT.601limited range即Y范围16-235、U/V范围16-240R Y 1.402 * (V - 128) G Y - 0.344 * (U - 128) - 0.714 * (V - 128) B Y 1.772 * (U - 128)注意如果输入YUV不是limited range而是full range这个公式的系数就要改。现在很多摄像头采集出来的是full range用这套公式会偏色。判断方法很简单纯白区域看Y值是不是235左右。如果是255就是full range。两种范围的选择会影响最终图片的色彩表现做转换前最好确认好输入源的类型。另外U和V的顺序也是个经典陷阱。YUV420在内存里是先U后V但有一些格式叫YV12是先V后U。如果发现转出来的图片红色和蓝色对调、整体偏紫首先检查U/V顺序是不是反了。2.3 libjpeg的编码流程记住这条调用链libjpeg的编码流程非常固定官方文档和示例代码都写得清楚核心调用链大概是声明struct jpeg_compress_struct和struct jpeg_error_mgr注册错误处理。调用jpeg_create_compress初始化编码器。指定输出文件jpeg_stdio_dest。设置图像宽、高、输入色彩空间JCS_RGB和压缩质量jpeg_set_quality。调用jpeg_start_compress开始编码。逐行调用jpeg_write_scanlines写入RGB数据。调用jpeg_finish_compress结束编码然后jpeg_destroy_compress释放资源。整条链路没有特别复杂的逻辑但有一个细节很多人忽略jpeg_write_scanlines要求输入数据是“行连续”的也就是每一行是RGBRGBRGB...这样的像素排列而不是分三个平面存放。所以我们需要先把YUV的平面数据转成RGB的连续缓冲区再一行一行喂给libjpeg而不能直接把YUV平面数据丢进去。3. 实操过程从YUV420到JPG的完整代码实现3.1 代码结构设计我在实际开发中使用的是一个C语言核心函数输入是YUV数据指针、宽和高输出是JPG文件。代码分两层底层先做YUV到RGB的转换每一行只转换当前需要的像素上层循环读取扫描线并调用jpeg_write_scanlines写入。为什么要一行一行处理而不是整个图像转换完再编码因为一张大图比如4K转换出来的RGB缓冲区动辄几十兆内存开销比较大而逐行转换只需要缓存一行RGB数据内存占用少还方便以后做实时视频帧编码。结构大致长这样输入YUV420数据I420排列、宽度、高度、输出文件路径。中间步骤1解析YUV三个平面的偏移地址。中间步骤2为每一行分配RGB缓冲用查表法完成颜色转换。中间步骤3调用libjpeg逐行写入。3.2 核心代码YUV420转RGB转换部分的代码我建议用整数运算代替浮点运算速度更快、精度也够。因为公式里的小数系数可以放大成整数再右移。我用了经典的“先乘以系数再右移12位”的定点数方法static void yuv420_to_rgb_row(const unsigned char* yuv_data, int width, int height, int row, unsigned char* rgb_row) { int col; const unsigned char* y_plane yuv_data; const unsigned char* u_plane yuv_data width * height; const unsigned char* v_plane u_plane (width / 2) * (height / 2); for (col 0; col width; col) { int y y_plane[row * width col]; int u u_plane[(row / 2) * (width / 2) col / 2]; int v v_plane[(row / 2) * (width / 2) col / 2]; int r y ((1436 * (v - 128)) 10); int g y - ((352 * (u - 128) 731 * (v - 128)) 10); int b y ((1815 * (u - 128)) 10); r r 0 ? 0 : (r 255 ? 255 : r); g g 0 ? 0 : (g 255 ? 255 : g); b b 0 ? 0 : (b 255 ? 255 : b); rgb_row[col * 3 0] (unsigned char)r; rgb_row[col * 3 1] (unsigned char)g; rgb_row[col * 3 2] (unsigned char)b; } }这里1436、352、731、1815是对应公式系数放大后的整数近似值配合右移10位省掉浮点运算。当然你也可以直接用浮点公式结果差不多只是整数方案在低端嵌入式平台上性能优势更明显。3.3 核心代码libjpeg逐行写入YUV转换准备好之后编码部分就很简单了。我贴一下核心写法static int yuv420_to_jpeg(const unsigned char* yuv_data, int width, int height, const char* filename, int quality) { struct jpeg_compress_struct cinfo; struct jpeg_error_mgr jerr; FILE* outfile; int row; unsigned char* rgb_row; if ((outfile fopen(filename, wb)) NULL) { fprintf(stderr, cant open %s\n, filename); return -1; } cinfo.err jpeg_std_error(jerr); jpeg_create_compress(cinfo); jpeg_stdio_dest(cinfo, outfile); cinfo.image_width width; cinfo.image_height height; cinfo.input_components 3; cinfo.in_color_space JCS_RGB; jpeg_set_defaults(cinfo); jpeg_set_quality(cinfo, quality, TRUE); jpeg_start_compress(cinfo, TRUE); rgb_row (unsigned char*)malloc(width * 3); if (rgb_row NULL) { jpeg_destroy_compress(cinfo); fclose(outfile); return -1; } while (cinfo.next_scanline cinfo.image_height) { yuv420_to_rgb_row(yuv_data, width, height, (int)cinfo.next_scanline, rgb_row); jpeg_write_scanlines(cinfo, rgb_row, 1); } free(rgb_row); jpeg_finish_compress(cinfo); jpeg_destroy_compress(cinfo); fclose(outfile); return 0; }这段代码从cinfo.next_scanline拿到当前需要写入的行号交给YUV转换函数转完一行RGB数据立刻写入JPG文件。用这种方式整个转换过程只需要缓存一行RGB即使处理超大尺寸图片内存占用也可以接受。有几个地方需要说明jpeg_set_quality的第二个参数传TRUE表示使用推荐的下采样表。如果传FALSE会用更精细的色度保留但文件会更大。日常使用传TRUE就够了。质量值我建议设在75到90之间低于70会出现明显的块状压缩痕迹高于95文件体积会暴涨但肉眼几乎看不出区别。4. 常见问题与排查技巧实录4.1 转出来的图片整体偏绿或偏暗这是YUV转换里最典型的问题。偏绿十有八九是U/V分量没读到或者读到的U/V值全是同一个固定值比如128。我排查过一起偏绿案例最后发现YUV数据源本身的U/V平面是隔行存放的而不是标准的I420排列相当于数据的“色度采样”方式和我们预期的不一致。解决办法先打印出几个像素点的Y、U、V原始值验证是否符合YUV420的布局规律再决定是否调整采样方式。偏暗通常是亮度范围问题。如果输入是full rangeY值范围0-255但代码按limited rangeY值16-235公式处理会导致暗部细节被压缩、整体画面发闷。确认方法是用十六进制查看工具检查一帧数据看白色区域的Y值是不是接近255而不是235左右。4.2 图片尺寸不对出现倾斜或花屏花屏、倾斜、颜色错乱八成是宽高参数和实际数据不匹配。YUV没有文件头系统不会告诉你这张图是1920x1080还是1280x720全凭外部指定。如果宽高设置错了Y平面和U/V平面的边界会错位图像自然就花了。另外要特别注意行的对齐问题。有些YUV数据每一行末尾有填充字节比如V4L2采集出来的数据每行可能按16或32字节对齐行号对应的偏移不是简单的row * width而是row * stride。如果你的输入来自采集设备先查一下驱动的bytesperline参数这个值往往不等于宽度直接用宽度计算就会得到歪斜的图像。4.3 libjpeg初始化报错或者内存崩溃libjpeg本身很稳定大部分崩溃都发生在调用前的数据准备阶段。比如RGB缓冲分配不足malloc(width * 3)是常规做法但如果宽高很大这个分配也可能失败。代码里一定要检查malloc返回值否则传入NULL指针会直接段错误。还有一种情况是jpeg_create_compress和jpeg_destroy_compress不配对比如在某个错误分支提前返回时忘了销毁编码器。libjpeg内部有动态分配的资源不销毁会导致内存泄漏。长时间跑转换任务的程序如果发现内存持续上涨优先检查错误处理路径里是不是漏了清理。4.4 U/V顺序不对导致颜色偏紫或红蓝互换颜色整体偏紫尤其是红色和蓝色对调基本可以确定是U/V平面读反了。标准YUV420I420的排列是Y U V而YV12的排列是Y V U。如果你手里的数据是YV12但代码按I420处理转出来的红蓝就会严重错乱。遇到这种情况最简单的方法就是把U和V两个指针的偏移交换一下重新编译运行大多数情况下能直接修复。5. 扩展思路从单帧转换到多帧视频与实时预览这套YUV转JPG的核心逻辑做扩展非常顺手。把单帧转换放进一个循环就能批量处理一个视频片段的若干帧把输入改成实时采集的YUV帧就能实现类似“摄像头抓拍存图”的功能。我实际项目中做过一个方案从H.264解码器拿到YUV420帧用这套代码实时编码成JPG用于检测到异常时抓拍现场画面。当时为了保证性能把RGB转换部分做成了查表法——因为YUV转RGB计算里的系数是固定的可以提前建好Y、U、V三个分量对应的R/G/B查找表转换时只查表不做乘法速度能提升不少。对于嵌入式场景这块优化非常值得做。顺便说一句很多朋友问“微信dat文件转jpg”是不是类似的原理。其实思路是相通的——微信的dat文件本质上是把JPG文件做了简单的异或加密剥掉处理之后还是JPG。如果你能理解“原始数据经过一定处理变成可见图片”的流程做这类工具就不会一头雾水。现在还有一种新的图像格式叫HEIF/HEIC压缩效率比JPEG高很多但兼容性远不如JPEG——很多老设备、老软件打不开。所以目前JPEG依然是通用的图像交换标准YUV转JPG这项技能还远没有过时。6. 写在最后的一些经验YUV转JPG这个项目看起来很小但真把每一步的“为什么”弄明白之后看很多视频图像处理问题都会有豁然开朗的感觉。以前我做这事也是直接从网上抄代码直到有一次转出来的图片颜色始终不对才被迫把YUV的排列方式、libjpeg的内部逻辑一点点啃明白。现在回看最值得花时间的反而是理解YUV布局和转换公式而不是编码调用部分。如果现在让我重新做一个类似工具我会优先把“输入格式检测”这个模块做好读文件大小、反推可能的格式、自动判断是I420还是NV12、是full range还是limited range。有了这一层工具对普通用户才真的好用。希望这篇文章能帮你少走点弯路要是你手头正好有打不开的.yuv文件按上面的代码试试应该很快能看到第一张正常的JPG。本文还有配套的精品资源点击获取 基于libjpeg的YUV420转JPEG编码实现与踩坑指南
简介这是一个基于libjpeg的YUV转JPEG示例工程面向图像处理、视频编码方向的开发者演示如何借助libjpeg库将YUV色彩空间数据编码为JPEG文件。压缩包内共8个文件包含1个C源文件yuvtojpeg.c、4个头文件jpeglib.h、jconfig.h、jerror.h、jmorecfg.h、2个静态库libjpeg.a和1个libjpeg.la库文件整体仅463KB结构紧凑适合作为轻量级参考工程。源码详细展示了初始化压缩结构、设置输出目标、YUV到RGB转换、jpeg_write_scanlines逐行写入、结束编码并释放资源等关键流程可帮助读者快速理解libjpeg的API调用顺序与JPEG编码原理。同时资源中的静态库与头文件已配套齐全能够直接用于编译测试免去自行构建依赖的麻烦。目前已有1226人学习下载适合需要在实际项目中实现YUV转JPG功能或正在学习图像编码原理的开发人员参考复用。 搞视频处理的人十有八九都遇到过这个场景手里拿到一个几百MB的.yuv文件双击打不开Windows自带的图片查看器完全不认识网上搜“yuv 打开”翻半天下了几个播放器还是花屏。说白了YUV是摄像头、编解码器最常用的原始图像格式它没有文件头、没有宽高信息就是一堆裸数据普通看图软件根本不知道该怎么解析。这篇文章要聊的就是基于libjpeg库把YUV数据编码成JPG图片的一套完整方案。我会从格式原理讲到代码实现再补上我实际调试中踩过的坑适合正在做视频采集、图像处理或者单纯被.yuv文件折磨得头疼的同学参考。1. 项目背景为什么会有“YUV转JPG”这种需求1.1 从打不开的.yuv文件说起很多人第一次接触YUV不是因为在做视频开发而是因为拿到了一个后缀是.yuv的文件。这个文件可能来自某个视频采集设备、某段摄像头测试视频或者某个聊天工具缓存出来的原始数据。Windows下没有默认的YUV打开软件因为这个格式本身就不是给人直接看的——它是给程序用的中间数据。YUV和RGB一样都是描述颜色的方式。区别在于RGB把颜色拆成红绿蓝三个分量每个像素都要存三个值而YUV把亮度Y和颜色U、V分开存储。人眼对亮度敏感、对颜色不敏感所以视频编码领域几乎都是先把RGB转成YUV再对色度分量做压缩采样这样可以省掉大量存储和带宽。摄像头采集出来的原始数据、H.264编码器的输入输出很多都是YUV格式。这就带来一个现实问题视频做完了、采集程序写完了你总得看一眼效果吧总得截个图发给同事确认吧YUV不能直接预览最简单的办法就是把它转成JPG。JPG是通用格式任何设备、任何软件都能打开传输也方便。所以“YUV转JPG”这个需求几乎是所有做视频图像相关开发的人绕不过去的一道坎。1.2 为什么选择libjpeg作为编码核心把YUV转成JPG方案其实有好几种。最省事的方案是直接调OpenCV的imwrite函数但它内部用的是自己的编码器而且依赖整个OpenCV库就为一个编码功能引进来一个大块头有点不划算。还有一种方案是走FFmpeg功能确实强大但配置复杂而且为了一个简单的格式转换去拉整个FFmpeg学习和工程成本偏高。libjpeg就不一样了它是专门做JPEG编码解码的C语言库轻量、稳定、可移植性极强从单片机到服务器都能跑。它只负责JPEG这一件事我们只需要自己处理YUV到RGB的转换然后把RGB数据交给libjpeg按行编码就行。这种“自己控制颜色转换、用libjpeg专注编码”的分工方式逻辑清晰不管是嵌入式开发还是桌面应用都适用没有任何多余的依赖踩坑也少。2. 核心原理YUV和libjpeg是怎么配合的2.1 YUV420的采样布局搞错一个像素就全乱套在动手写代码之前必须把YUV的内存布局搞清楚。最常见的YUV格式是YUV420也叫I420它采用4:2:0色度采样每4个亮度像素共享一组色度像素。也就是说Y分量是一个wh的平面U分量是(w/2)(h/2)的平面V分量也是(w/2)*(h/2)的平面三个平面依次排列在内存里。用数据说话。一张1280x720的YUV420图片Y分量有1280x720921600个字节U和V分量各是640x360230400个字节。整个文件大小就是9216002304002304001382400字节。如果你手里的.yuv文件大小刚好等于这个值那它基本就是YUV420格式如果不是那可能是YUV422、YUV444或者是加了文件头需要另做处理。这里有一个新手最容易踩的坑YUV420的U、V平面只有宽高的一半但很多人在代码里习惯性用w*h去遍历结果越界读取读出来的颜色数据完全是垃圾值最后编码出来的图片要么绿油油的要么花屏。做转换之前第一件事就是确认输入YUV的格式和宽高再用验证文件大小的方式来反推格式这一步能省掉后面大量排查时间。2.2 YUV转RGB的换算公式和色彩空间选择libjpeg不认识YUV它默认的输入色彩空间是RGB所以我们得先把YUV转成RGB。这个转换公式很多人手写时有细微差别不同亮度范围full range还是limited range公式还不一样我在这里给出最常用的一套标准定义BT.601limited range即Y范围16-235、U/V范围16-240R Y 1.402 * (V - 128) G Y - 0.344 * (U - 128) - 0.714 * (V - 128) B Y 1.772 * (U - 128)注意如果输入YUV不是limited range而是full range这个公式的系数就要改。现在很多摄像头采集出来的是full range用这套公式会偏色。判断方法很简单纯白区域看Y值是不是235左右。如果是255就是full range。两种范围的选择会影响最终图片的色彩表现做转换前最好确认好输入源的类型。另外U和V的顺序也是个经典陷阱。YUV420在内存里是先U后V但有一些格式叫YV12是先V后U。如果发现转出来的图片红色和蓝色对调、整体偏紫首先检查U/V顺序是不是反了。2.3 libjpeg的编码流程记住这条调用链libjpeg的编码流程非常固定官方文档和示例代码都写得清楚核心调用链大概是声明struct jpeg_compress_struct和struct jpeg_error_mgr注册错误处理。调用jpeg_create_compress初始化编码器。指定输出文件jpeg_stdio_dest。设置图像宽、高、输入色彩空间JCS_RGB和压缩质量jpeg_set_quality。调用jpeg_start_compress开始编码。逐行调用jpeg_write_scanlines写入RGB数据。调用jpeg_finish_compress结束编码然后jpeg_destroy_compress释放资源。整条链路没有特别复杂的逻辑但有一个细节很多人忽略jpeg_write_scanlines要求输入数据是“行连续”的也就是每一行是RGBRGBRGB...这样的像素排列而不是分三个平面存放。所以我们需要先把YUV的平面数据转成RGB的连续缓冲区再一行一行喂给libjpeg而不能直接把YUV平面数据丢进去。3. 实操过程从YUV420到JPG的完整代码实现3.1 代码结构设计我在实际开发中使用的是一个C语言核心函数输入是YUV数据指针、宽和高输出是JPG文件。代码分两层底层先做YUV到RGB的转换每一行只转换当前需要的像素上层循环读取扫描线并调用jpeg_write_scanlines写入。为什么要一行一行处理而不是整个图像转换完再编码因为一张大图比如4K转换出来的RGB缓冲区动辄几十兆内存开销比较大而逐行转换只需要缓存一行RGB数据内存占用少还方便以后做实时视频帧编码。结构大致长这样输入YUV420数据I420排列、宽度、高度、输出文件路径。中间步骤1解析YUV三个平面的偏移地址。中间步骤2为每一行分配RGB缓冲用查表法完成颜色转换。中间步骤3调用libjpeg逐行写入。3.2 核心代码YUV420转RGB转换部分的代码我建议用整数运算代替浮点运算速度更快、精度也够。因为公式里的小数系数可以放大成整数再右移。我用了经典的“先乘以系数再右移12位”的定点数方法static void yuv420_to_rgb_row(const unsigned char* yuv_data, int width, int height, int row, unsigned char* rgb_row) { int col; const unsigned char* y_plane yuv_data; const unsigned char* u_plane yuv_data width * height; const unsigned char* v_plane u_plane (width / 2) * (height / 2); for (col 0; col width; col) { int y y_plane[row * width col]; int u u_plane[(row / 2) * (width / 2) col / 2]; int v v_plane[(row / 2) * (width / 2) col / 2]; int r y ((1436 * (v - 128)) 10); int g y - ((352 * (u - 128) 731 * (v - 128)) 10); int b y ((1815 * (u - 128)) 10); r r 0 ? 0 : (r 255 ? 255 : r); g g 0 ? 0 : (g 255 ? 255 : g); b b 0 ? 0 : (b 255 ? 255 : b); rgb_row[col * 3 0] (unsigned char)r; rgb_row[col * 3 1] (unsigned char)g; rgb_row[col * 3 2] (unsigned char)b; } }这里1436、352、731、1815是对应公式系数放大后的整数近似值配合右移10位省掉浮点运算。当然你也可以直接用浮点公式结果差不多只是整数方案在低端嵌入式平台上性能优势更明显。3.3 核心代码libjpeg逐行写入YUV转换准备好之后编码部分就很简单了。我贴一下核心写法static int yuv420_to_jpeg(const unsigned char* yuv_data, int width, int height, const char* filename, int quality) { struct jpeg_compress_struct cinfo; struct jpeg_error_mgr jerr; FILE* outfile; int row; unsigned char* rgb_row; if ((outfile fopen(filename, wb)) NULL) { fprintf(stderr, cant open %s\n, filename); return -1; } cinfo.err jpeg_std_error(jerr); jpeg_create_compress(cinfo); jpeg_stdio_dest(cinfo, outfile); cinfo.image_width width; cinfo.image_height height; cinfo.input_components 3; cinfo.in_color_space JCS_RGB; jpeg_set_defaults(cinfo); jpeg_set_quality(cinfo, quality, TRUE); jpeg_start_compress(cinfo, TRUE); rgb_row (unsigned char*)malloc(width * 3); if (rgb_row NULL) { jpeg_destroy_compress(cinfo); fclose(outfile); return -1; } while (cinfo.next_scanline cinfo.image_height) { yuv420_to_rgb_row(yuv_data, width, height, (int)cinfo.next_scanline, rgb_row); jpeg_write_scanlines(cinfo, rgb_row, 1); } free(rgb_row); jpeg_finish_compress(cinfo); jpeg_destroy_compress(cinfo); fclose(outfile); return 0; }这段代码从cinfo.next_scanline拿到当前需要写入的行号交给YUV转换函数转完一行RGB数据立刻写入JPG文件。用这种方式整个转换过程只需要缓存一行RGB即使处理超大尺寸图片内存占用也可以接受。有几个地方需要说明jpeg_set_quality的第二个参数传TRUE表示使用推荐的下采样表。如果传FALSE会用更精细的色度保留但文件会更大。日常使用传TRUE就够了。质量值我建议设在75到90之间低于70会出现明显的块状压缩痕迹高于95文件体积会暴涨但肉眼几乎看不出区别。4. 常见问题与排查技巧实录4.1 转出来的图片整体偏绿或偏暗这是YUV转换里最典型的问题。偏绿十有八九是U/V分量没读到或者读到的U/V值全是同一个固定值比如128。我排查过一起偏绿案例最后发现YUV数据源本身的U/V平面是隔行存放的而不是标准的I420排列相当于数据的“色度采样”方式和我们预期的不一致。解决办法先打印出几个像素点的Y、U、V原始值验证是否符合YUV420的布局规律再决定是否调整采样方式。偏暗通常是亮度范围问题。如果输入是full rangeY值范围0-255但代码按limited rangeY值16-235公式处理会导致暗部细节被压缩、整体画面发闷。确认方法是用十六进制查看工具检查一帧数据看白色区域的Y值是不是接近255而不是235左右。4.2 图片尺寸不对出现倾斜或花屏花屏、倾斜、颜色错乱八成是宽高参数和实际数据不匹配。YUV没有文件头系统不会告诉你这张图是1920x1080还是1280x720全凭外部指定。如果宽高设置错了Y平面和U/V平面的边界会错位图像自然就花了。另外要特别注意行的对齐问题。有些YUV数据每一行末尾有填充字节比如V4L2采集出来的数据每行可能按16或32字节对齐行号对应的偏移不是简单的row * width而是row * stride。如果你的输入来自采集设备先查一下驱动的bytesperline参数这个值往往不等于宽度直接用宽度计算就会得到歪斜的图像。4.3 libjpeg初始化报错或者内存崩溃libjpeg本身很稳定大部分崩溃都发生在调用前的数据准备阶段。比如RGB缓冲分配不足malloc(width * 3)是常规做法但如果宽高很大这个分配也可能失败。代码里一定要检查malloc返回值否则传入NULL指针会直接段错误。还有一种情况是jpeg_create_compress和jpeg_destroy_compress不配对比如在某个错误分支提前返回时忘了销毁编码器。libjpeg内部有动态分配的资源不销毁会导致内存泄漏。长时间跑转换任务的程序如果发现内存持续上涨优先检查错误处理路径里是不是漏了清理。4.4 U/V顺序不对导致颜色偏紫或红蓝互换颜色整体偏紫尤其是红色和蓝色对调基本可以确定是U/V平面读反了。标准YUV420I420的排列是Y U V而YV12的排列是Y V U。如果你手里的数据是YV12但代码按I420处理转出来的红蓝就会严重错乱。遇到这种情况最简单的方法就是把U和V两个指针的偏移交换一下重新编译运行大多数情况下能直接修复。5. 扩展思路从单帧转换到多帧视频与实时预览这套YUV转JPG的核心逻辑做扩展非常顺手。把单帧转换放进一个循环就能批量处理一个视频片段的若干帧把输入改成实时采集的YUV帧就能实现类似“摄像头抓拍存图”的功能。我实际项目中做过一个方案从H.264解码器拿到YUV420帧用这套代码实时编码成JPG用于检测到异常时抓拍现场画面。当时为了保证性能把RGB转换部分做成了查表法——因为YUV转RGB计算里的系数是固定的可以提前建好Y、U、V三个分量对应的R/G/B查找表转换时只查表不做乘法速度能提升不少。对于嵌入式场景这块优化非常值得做。顺便说一句很多朋友问“微信dat文件转jpg”是不是类似的原理。其实思路是相通的——微信的dat文件本质上是把JPG文件做了简单的异或加密剥掉处理之后还是JPG。如果你能理解“原始数据经过一定处理变成可见图片”的流程做这类工具就不会一头雾水。现在还有一种新的图像格式叫HEIF/HEIC压缩效率比JPEG高很多但兼容性远不如JPEG——很多老设备、老软件打不开。所以目前JPEG依然是通用的图像交换标准YUV转JPG这项技能还远没有过时。6. 写在最后的一些经验YUV转JPG这个项目看起来很小但真把每一步的“为什么”弄明白之后看很多视频图像处理问题都会有豁然开朗的感觉。以前我做这事也是直接从网上抄代码直到有一次转出来的图片颜色始终不对才被迫把YUV的排列方式、libjpeg的内部逻辑一点点啃明白。现在回看最值得花时间的反而是理解YUV布局和转换公式而不是编码调用部分。如果现在让我重新做一个类似工具我会优先把“输入格式检测”这个模块做好读文件大小、反推可能的格式、自动判断是I420还是NV12、是full range还是limited range。有了这一层工具对普通用户才真的好用。希望这篇文章能帮你少走点弯路要是你手头正好有打不开的.yuv文件按上面的代码试试应该很快能看到第一张正常的JPG。本文还有配套的精品资源点击获取