打包图像的字节顺序答案

【问题标题】：Byte order for packed images打包图像的字节顺序
【发布时间】：2014-04-25 15:09:25
【问题描述】：

所以从http://en.wikipedia.org/wiki/RGBA_color_space，我了解到在某些解释中，ARGB 的字节顺序是从最低地址到最高地址 BGRA，在小端机器上。

这如何影响打包数据的命名约定，例如uint8_t ar[]={R,G,B,R,G,B,R,G,B}？

【问题讨论】：

标签： c++ c rgb

【解决方案1】：

根据定义，Little endian 以相反的顺序存储数字的字节。如果您将它们视为字节数组，这并不是绝对必要的，但是任何模糊有效的代码库实际上会将 4 个字节视为 32 位无符号整数。这将使软件块传输速度提高近 4 倍。

现在真正的问题是为什么。这是因为当如上所述将像素视为 32 位 int 时，编码人员希望能够以可预测的方式运行算术和移位。这依赖于字节顺序相反。

简而言之，这实际上并不奇怪，因为在小端机器中，最后一个字节（最高地址）实际上是最重要的字节，而第一个是最不重要的字节。因此，这样的字段自然会以相反的顺序排列，因此当被视为数字时，它是正确的方式（作为数字，它将显示为 ARGB，但作为字节数组，它将显示为 BGRA）。

抱歉，如果不清楚，但我希望它有所帮助。如果您不明白或我遗漏了什么，请发表评论。

【讨论】：

我明白这一点。我不明白这是如何映射到打包数据类型的：它似乎不能？
@MadScienceDreams 看来主要区别在于打包版本只是缺少 alpha 通道。您应该能够通过一些按位移位和内存副本相当轻松地在两者之间进行转换。
我知道如何转换它。 ARGB“命名约定”是按像素值，而不是字节顺序。但是相同的命名约定对于打包数据类型没有意义。在比较字节空间时，[RGBR] 和 [BGRB] 是非常不同的值。如果您将像素值定义为 (value>>8)，该约定仍然可以成立，但这似乎......很奇怪。

【解决方案2】：

如果您将数据存储在指定的字节数组中，则您使用的是基本上是 RGB 反转的 BGR 格式：

【讨论】：