c++ - libjpeg/libjpeg-turbo RGBA/32位int解压

Question

当使用 libjpeg 将图像输入 OpenCL 时，为了能够将 channel 视为具有 CL_UNORM_INT8(在 [0.0, 1.0] 范围内 float )的规范化 uint8，您只能用 4 个 channel 组件为它提供缓冲区。这是有问题的，因为 libjpeg 只输出 3(默认情况下按 RGB 顺序)，因为 JPEG 没有不透明度的概念。

我看到的唯一解决方法是使用 libjpeg 扫描线，然后复制一个适当长度的缓冲区(为扫描线中的每个像素添加第四个 channel 组件)，然后 memcpy 值，将每个的 alpha 分量设置为 255。如果你很狡猾，你甚至可以就地执行此操作并将缓冲区初始化为 row_stride * 4，然后从索引 row_stride * 3 - 1 向后移动到 0，将组件移动到完整缓冲区中的适当位置(并在必要时为 alpha 添加 255)。

但是，这感觉很老套，如果您正在处理大图像(我就是)，那么让这个额外的传递(聚合)整个图像是 Not Acceptable 。

那么，有没有办法让 libjpeg 将组件的数量扩展到 4？我尝试在 cinfo 上设置属性，例如 output_components，但无济于事。我读到过唯一的解决方法是使用 jmorecfg.h 中设置的常量 RGB_COMPONENTS = 4 编译一个特殊版本的 libjpeg，但这肯定不便于移植或者对于这种(常见的)输出变化所必需的事情。

Answer 1

事实证明，最好的解决方案(至少，不需要任何自定义构建库或额外通过缓冲区的解决方案)是使用 libjpeg-turbo。从 1.1.90 开始，他们提供了一个颜色空间常量 JCS_EXT_RGBX，它添加了一个假的 alpha channel 。据我所知这是only documented in the release notes of a beta version on SourceForge因此，除非该 URL 更改或不再存在(阅读:互联网反抗 sf 将代码阴暗地插入到“不活跃”的流行存储库中，并且他们被迫关闭)，这是相关的位转载:

When decompressing a JPEG image using an output colorspace of JCS_EXT_RGBX, JCS_EXT_BGRX, JCS_EXT_XBGR, or JCS_EXT_XRGB, libjpeg-turbo will now set the unused byte to 0xFF, which allows applications to interpret that byte as an alpha channel (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 的像素返回额外的第四个分量。