2

当使用 libjpeg 将图像输入 OpenCL 时，为了能够将通道视为标准化的 uint8 CL_UNORM_INT8（浮点数在 range 内[0.0, 1.0]），您只能将其输入具有 4 个通道分量的缓冲区。这是有问题的，因为 libjpeg 只输出 3（默认情况下按 RGB 顺序），因为 JPEG 没有不透明度的概念。

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

但是，这感觉很麻烦，如果您正在处理大图像（我是），那么让这个额外的传递（将汇总）整个图像是不可接受的。

那么，有没有办法让 libjpeg 将组件的数量扩展到 4 个？我尝试过设置属性cinfo，output_components但无济于事。我读过唯一的解决方法是编译一个特殊版本的 libjpeg 并设置常量RGB_COMPONENTS = 4in jmorecfg.h，但这肯定感觉不便携，或者对于这种（常见）输出更改而言是必要的。

4

1 回答 1

2

所以事实证明，最好的解决方案（至少，不需要任何自定义构建库或额外通过缓冲区的解决方案）是使用 libjpeg-turbo。从 1.1.90 开始，它们提供了一个颜色空间常量JCS_EXT_RGBX，该常量添加了一个假 alpha 通道。据我所知，这仅记录在 SourceForge 的 beta 版本的发行说明中，因此除非此 URL 更改或不再存在（阅读：互联网反对 sf 将代码阴暗地插入“非活动”流行存储库，它们是被迫关闭），这里是相关位转载：

JCS_EXT_RGBX当使用、JCS_EXT_BGRX、JCS_EXT_XBGR或的输出色彩空间解压缩 JPEG 图像时 JCS_EXT_XRGB，libjpeg-turbo 现在会将未使用的字节设置为0xFF，这允许应用程序将该字节解释为 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。

于 2015-07-03T04:52:33.757 回答