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 - 10,将组件移动到完整缓冲区中的适当位置(并255在必要时添加 alpha)。

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

那么,有没有办法让 libjpeg 将组件的数量扩展到 4 个?我尝试过设置属性cinfooutput_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_BGRXJCS_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 回答