JPEG 文件格式是否支持 RGB 数据？

Question

我正在做一些涉及使用 WIC 编码图像数据的编程。我使用了 RGB 数据，但 WIC 始终将其视为 BGR。我有一个关于 Stack Overflow处理编程方面的相关问题。但是，我想排除该问题可能与 WIC 或 JPEG 文件格式有关。

这是 JPEG 的正常行为，还是 WIC 如何处理图像数据？

Answer 1

这是根据 OP 在评论中提供的附加信息、SO 上的相关线程以及他自己的答案对我的答案的主要重写。

JPEG 文件格式是否支持 RGB 数据？

RGB有两个含义。

它是一个颜色空间，其中颜色是根据红色、绿色的原色定义的。和蓝色。JPEG 标准是以 RGB 色彩空间为起点的。出于压缩目的，它被转换为 YCbCr。这篇维基百科文章对编码和压缩过程进行了非常详尽的描述。
RGB 表示解释存储的颜色数据的顺序。Bob 的回答解释了为什么它也可以按 BGR 顺序进行解释。这就是导致导致这个问题的混乱的含义。它实际上与 JPEG 标准无关，而是与 WIC 处理数据的方式有关。

图像格式文件规范包括定义颜色序列。在这种情况下，情况并非如此。WIC 正在从原始图像数据创建 JPEG。根据您找到的链接，WIC 支持输入数据的 RGB 和 BGR 顺序，尽管它仅将 BGR 列为其原生 JPEG 编解码器的输入。因此，问题在于与 WIC 交互并为其提供预期的内容。

我怀疑这是在为 WIC 提供它期望看到的东西。如果它现在可以工作，它必须在您更改的编码中。听起来像是与 WIC 接口的问题。Microsoft 可能需要有人根据您之前的代码解释为什么 WIC 会以这种方式执行。 (2认同)
@AlexMazzariol 与 OpenGL 完全不同：有些东西（CPU、程序、协议、规范）使用小端，有些使用大端。碰巧的是，设备无关位图格式使用小端，并且未压缩图像数据的典型内存表示通常是 DIB。这实际上是在 OpenGL 1.0 发布之前 - 虽然两者可能相关，但 OpenGL 可能不是原因。 (2认同)

Answer 2

虽然可以控制 WIC 读取的实际数据格式，但请注意，设备无关位图格式通常用于未压缩的图像数据（也包含在大多数 BMP 文件中），将 24BPP 和 32BPP 格式的每个像素存储为单个 24 位或 32 位小端字。

这张图片很好地描述了 little-endian：

^{图片是公共领域，由RS Shaw 提供，来自Wikimedia Commons}

如您所见，最低有效字节在前，最高有效字节在后。32BPP ARGB 值将作为单独的 8 位字节 B、G、R、A 存储在内存和磁盘上。 24BPP RGB 值也是如此，以 B、G、R 的形式存储在内存中。

这可能解释了为什么 WIC 使用的默认格式似乎是“BGR” - 因为这是默认的内存中表示，并且转换为大端 RGB 将是额外的工作，除非明确要求，否则不会完成。

顺便说一下，人类通常将数字读为大端；以相反的顺序。同一个 24BPP/32BPP 字的大端字节表示将读取为 RGB 或 ARGB，更接近您的预期。