当使用libjpeg将图像提供给OpenCL时，为了能够将频道视为带有CL_UNORM_INT8的标准化uint8（浮动范围为[0.0, 1.0]），您只能使用它来提供缓冲区4通道组件。这是有问题的，因为libjpeg只输出3（默认为RGB顺序），因为JPEG没有不透明度的概念。
我看到的唯一解决方法是使用libjpeg扫描线，然后制作适当长度的复制缓冲区（为扫描线中的每个像素添加第四个通道组件），然后memcpy将值设置为，设置每个的255 alpha分量。如果你很棘手并且最初将缓冲区初始化为row_stride * 4然后从索引row_stride * 3 - 1向后移动到0，那么你甚至可以在适当的位置执行此操作，将组件移动到适当的位置完整缓冲区（并在必要时为alpha添加255）。
然而，这感觉很麻烦，如果你正在处理大图像（我是），那么对整个图像进行额外的传递（聚合会是什么）是不可接受的。
那么，有没有办法让libjpeg只将组件数量扩展到4？我尝试在cinfo output_components上设置属性，但无效。我已经读过，唯一的解决方法是使用RGB_COMPONENTS = 4中设置的常量jmorecfg.h来编译特殊版本的libjpeg，但这确实不具备可移植性或者对于这种（常见的）产出变化。
答案 0 :(得分：1)
事实证明，最好的解决方案（至少，不需要任何自定义构建的lib或通过缓冲区的额外传递）是使用libjpeg-turbo。从1.1.90开始，它们提供了一个颜色空间常量JCS_EXT_RGBX，它增加了一个假的alpha通道。据我所知，这是only documented in the release notes of a beta version on SourceForge，因此禁止此网址发生变化或不再存在（读取：互联网反对sf，因为它将代码阴影插入＆＃34;非活动＆＃34;热门回购和他们被迫关闭），这里有相关位转载：
使用输出色彩空间解压缩JPEG图像时
JCS_EXT_RGBX，JCS_EXT_BGRX，JCS_EXT_XBGR或JCS_EXT_XRGB，libjpeg-turbo将会 现在将未使用的字节设置为0xFF，这允许应用程序解释它 byte作为alpha通道（0xFF= opaque）。
请注意，如果您需要，这也允许其他排序，例如BGR。
要在jpeg_read_header()通话后使用它（因为此通话会在cinfo上设置成员，我们需要默认设置），但在jpeg_start_decompress()通话之前（因为它使用此值成员），添加：
cinfo.out_color_space = JCS_EXT_RGBX; // or JCS_EXT_XRGB, JCS_EXT_BGRX, etc.
现在在解压缩期间扫描线将为每个像素集返回额外的第四个分量255。