1. 问题

Android中在使用RGB数据的时候我们会遇到color space 的stored in computer memory的问题。
通常有两种典型的格式来记录RGB数据:

1. byte order——按照字节顺序
2. word order——按照字面顺序

• 大端字节序的环境 big-endian system
  • byte order和Word order的顺序是一致的
• 小端字节序 little-endian system
  • byte order 和 word order 是相反的,比如 ARGB(word-order)的内存字节序存储为BGRA(byte order)

所以，我们在Android中使用RGB数据的时候是使用哪种scheme(word order | byte order)标记的format一定要清楚。

2. libyuv

2.1 FOURCC (Four Charactacter Code)

在下载的libyuv源码里libyuv-refs-heads-master\docs\formats.md里有讲述libyuv支持的FOURCC(这里)：

On little endian machines, as an int, this would have 'A' in the lowest byte. The FOURCC macro reverses the order:

#define FOURCC(a, b, c, d) (((uint32)(a)) | ((uint32)(b) << 8) | ((uint32)(c) << 16) | ((uint32)(d) << 24))

So the "ARGB" string, read as an uint32, is

FOURCC_ARGB = FOURCC('A', 'R', 'G', 'B')

If you were to read ARGB pixels as uint32's, the alpha would be in the high byte, and the blue in the lowest byte. In memory, these are stored little endian, so 'B' is first, then 'G', 'R' and 'A' last.

2.2 libyuv中FOURCC

libyuv使用C/C++语言，是小端字节序。所以word order和byte order是相反的。看libyuv的源码也能看得出来。
在源码row_common.cc文件中

MAKEROWY(ARGB, 2, 1, 0, 4)  //ARGB(word order)-->BGRA(byte order)-->2,1,0-->RGB
MAKEROWY(BGRA, 1, 2, 3, 4)  //BGRA(word order)-->ARGB(byte order)-->1,2,3-->RGB
MAKEROWY(ABGR, 0, 1, 2, 4)  //ABGR(word order)-->RGBA(byte order)-->0,1,2-->RGB
MAKEROWY(RGBA, 3, 2, 1, 4)
MAKEROWY(RGB24, 2, 1, 0, 3)

MAKEROWY(ARGB, 2, 1, 0, 4)中ARGB是使用的word order,所以它的byte order是BGRA，后面的2,1,0,是字节序中的索引，每个取出来后刚好是RGB。

convert.h中的注释

3. Bitmap

当我们在JNI中使用Bitmap时，需要取出pixel数据的时候同样涉及到实际的内存字节序问题,只有正确知道了字节序也就是byte order,我们才能正确的转换。

• ANDROID_BITMAP_FORMAT_RGBA_8888
  • 这里的RGBA_8888是byte order

而在应用层Bitmap.Config.ARGB_8888,由于java是大端字节序,word order和byte order是一样的

RGBA color space