libjpeg/libjpeg-turbo RGBA/32位int解压缩

Question

当使用libjpeg向OpenCL提供图像时，为了能够使用CL_UNORM_INT8 (范围[0.0, 1.0]中的浮点数)将通道视为标准化的uint8 8，您只能向它提供4个通道组件的缓冲区。这是有问题的，因为libjpeg只输出3(默认为RGB顺序)，因为JPEG没有不透明的概念。

我看到的唯一解决办法是使用libjpeg扫描行，然后创建一个适当长度的重复缓冲区(为扫描行中的每个像素添加第四个通道组件)，然后将值设置为memcpy，为每个像素设置alpha组件为255。如果您需要技巧，首先将缓冲区初始化为row_stride * 4，然后从索引row_stride * 3 - 1向后走到0，将组件移动到完整缓冲区中的适当位置(并在必要时为alpha添加255 )，甚至可以这样做。

然而，这感觉很麻烦，如果您正在处理大型图像(我是这样的)，让这个额外的传递(将是什么)整个图像是不可接受的。

那么，是否有办法使libjpeg只将组件的数量扩展到4个？我尝试过在cinfo上设置属性，比如output_components，但没有效果。我已经读到过，唯一的解决办法是用RGB_COMPONENTS = 4中的常量jmorecfg.h编译一个特殊版本的libjpeg，但这肯定不是可移植的，对于这种(常见的)输出更改来说也不是必需的。

Answer 1

因此，最好的解决方案(至少，不需要任何定制的库构建或通过缓冲区的额外传递)是使用libjpeg-turbo。从1.1.90开始，它们提供了一个颜色空间常量JCS_EXT_RGBX，它添加了一个假的alpha通道。据我所知，这是只记录在SourceForge测试版的发行说明中。，除非该URL更改或不再存在(请阅读:互联网反对sf将代码插入到“非活动”的流行repos中，并被迫关闭)，以下是转载的相关比特：

当使用JCS_EXT_RGBX、JCS_EXT_BGRX、JCS_EXT_XBGR或JCS_EXT_XRGB的输出颜色空间对JPEG图像进行解压缩时，libjpeg-turbo现在将未使用的字节设置为0xFF，这允许应用程序将该字节解释为α通道(0xFF =不透明)。

请注意，如果您需要BGR这样的备用订单，也可以使用它们。

要在jpeg_read_header()调用之后使用它(因为这个调用在cinfo上设置了一个成员，我们需要默认设置)，但是要在jpeg_start_decompress()调用之前使用它(因为它使用了这个成员的值)，添加：

cinfo.out_color_space = JCS_EXT_RGBX; // or JCS_EXT_XRGB, JCS_EXT_BGRX, etc.

现在，解压缩过程中的扫描线将为设置为255的每个像素返回额外的第四个分量。