我正在做一些涉及使用 WIC 编码图像数据的编程。我使用了 RGB 数据，但 WIC 始终将其视为 BGR。我有一个Stack Overflow 上的相关问题处理编程方面的问题。但是，我想排除该问题可能与 WIC 或 JPEG 文件格式有关。
对于 JPEG 来说，这是正常行为吗？或者 WIC 如何处理图像数据？
答案1
这是根据 OP 在评论中提供的附加信息、SO 上的相关线程以及他自己的回答对我的答案进行的重大重写。
JPEG 文件格式是否支持 RGB 数据？
RGB有两层含义。
它是一个颜色空间，其中的颜色是根据红、绿和蓝的原色来定义的。JPEG 标准以 RGB 颜色空间为起点。为了进行压缩，它被转换为 YCbCr。在这篇维基百科文章。
RGB 表示对存储的颜色数据的解释顺序。Bob 的回答解释了为什么它也可以按 BGR 顺序进行解释。这就是导致这个问题的混淆的原因。它实际上与 JPEG 标准无关，而是与 WIC 如何处理数据有关。
图像格式文件规范包括定义颜色序列。但在本例中情况并非如此。WIC 正在从原始图像数据创建 JPEG。根据您找到的链接，WIC 支持输入数据的 RGB 和 BGR 顺序，尽管它仅将 BGR 列为其原生 JPEG 编解码器的输入。因此，问题在于与 WIC 交互并向其提供其期望看到的内容。
答案2
虽然可以控制 WIC 读取的实际数据格式，但请注意设备独立位图格式，通常用于未压缩的图像数据（也包含在大多数 BMP 文件中），以 24BPP 和 32BPP 格式将每个像素存储为单个 24 位或 32 位小端单词。
这张图很好地描述了小端序：
如您所见，最低有效字节在前，最高有效字节在后。32BPP ARGB 值将作为单独的 8 位字节 B、G、R、A 存储在内存和磁盘上。24BPP RGB 值也是如此，在内存中存储为 B、G、R。
这可能解释了为什么 WIC 使用的默认格式似乎是“BGR”——因为这是默认的内存表示，并且转换为大端 RGB 需要额外的工作，除非明确要求，否则不会完成。
顺便说一句，人类通常以大端方式读取数字；以相反的顺序。相同 24BPP/32BPP 字的大端字节表示将读取为 RGB 或 ARGB，更接近您期望的。