Question

I’m confused about PixelFormat on Android.

My device is Motorola Defy.

I have two questions:

• On Android 2.3 getWindowManager().getDefaultDisplay().getPixelFormat() returns 4 what stands for RGB_565. As far as I know my device has 16M colors, that means 3 (or 4 with alpha channel) bytes per pixel:

                2^(8*3) = 2^24 = 16M

But RGB_565 format has 2 bytes (16 bits) per pixel, what stands for 65K colors:

                2^(8*2) = 2^16 = 65K

So, why getPixelFormat() doesn’t return format with 3 (or 4 like RGBA) bytes per pixel? Is it display driver problems or something? Can I set PixelFormat to RGBA_8888 (or analogue)?

• On Android 4.1 (custom rom), getPixelFormat() returns 5. But this value is undocumented. What does it stand for? Actually, in this situation effect is the same as with constant 4. But from this discussion I found that 5 stands for RGBA_8888 (but there is no proof for that statement). So how can I figure out the real format of device’s screen? Also I found one Chinese device on Android 2.2, that also has PixelFormat 5, but the real format is 4 (as my Motorola).

I have googled these questions and found nothing. The only thing I found is that nexus 7 also has 5 format.

Update:

I found method getWindow().setFormat() but it actually does not change main pixel format.

Answer 1

I’ll just add my two cents to this discussion, though I should admit in advance that I could not find conclusive answers to all your questions.

So, why getPixelFormat() doesn’t return format with 3 (or 4 like RGBA)
bytes per pixel? Is it display driver problems or something? Can I set
PixelFormat to RGBA_8888 (or analogue)?

I’m a little puzzled about what you’re exactly asking here. The return value of getPixelFormat() is just an integer that provides a way of identifying the active pixel format; it is not meant to represent any data compacted into a number (e.g. as with MeasureSpec). Unfortunately, I do not have an explanation for why a different is returned than you expected. My best guess would be it’s either due to an OS decision, as there does not seem to be a limitation from a hardware point of view, or alternatively, the constants defined in the native implementation do not match up the ones in Java. The fact that you’re getting back a 4 as pixel format would then not necessarily mean that it’s really RGB_565, if Motorola messed up the definitions.

On a side note: I’ve actually come across misaligned constant definitions before in Android, although I can’t currently recall where exactly…

Just to confirm, it may be worth printing out the pixel format details at runtime. If there’s indeed a native constant defined that uses a Java PixelFormat value but doesn’t match up, you could possibly reveal the ‘real’ format this way. Use the getPixelFormatInfo(int format, PixelFormat info) method, that simply delegates retrieving the actual values from the native implementation.

On Android 4.1 (custom rom), getPixelFormat() returns 5. But this
value is undocumented. What does it stand for?

As mentioned earlier, sometimes constants defined in native code do not match up the ones in Java, or aren’t defined at all. This is probably such a case. You’ll have to do some digging to find out what it represents, but it’s fairly straightforward:

/**
 * pixel format definitions
 */

enum {
    HAL_PIXEL_FORMAT_RGBA_8888          = 1,
    HAL_PIXEL_FORMAT_RGBX_8888          = 2,
    HAL_PIXEL_FORMAT_RGB_888            = 3,
    HAL_PIXEL_FORMAT_RGB_565            = 4,
    HAL_PIXEL_FORMAT_BGRA_8888          = 5,
    HAL_PIXEL_FORMAT_RGBA_5551          = 6,
    HAL_PIXEL_FORMAT_RGBA_4444          = 7,
    /* 0x8 - 0xF range unavailable */
    HAL_PIXEL_FORMAT_YCbCr_422_SP       = 0x10,     // NV16
    HAL_PIXEL_FORMAT_YCrCb_420_SP       = 0x11,     // NV21 (_adreno)
    HAL_PIXEL_FORMAT_YCbCr_422_P        = 0x12,     // IYUV
    HAL_PIXEL_FORMAT_YCbCr_420_P        = 0x13,     // YUV9
    HAL_PIXEL_FORMAT_YCbCr_422_I        = 0x14,     // YUY2 (_adreno)
    /* 0x15 reserved */
    HAL_PIXEL_FORMAT_CbYCrY_422_I       = 0x16,     // UYVY (_adreno)
    /* 0x17 reserved */
    /* 0x18 - 0x1F range unavailable */
    HAL_PIXEL_FORMAT_YCbCr_420_SP_TILED = 0x20,     // NV12_adreno_tiled
    HAL_PIXEL_FORMAT_YCbCr_420_SP       = 0x21,     // NV12
    HAL_PIXEL_FORMAT_YCrCb_420_SP_TILED = 0x22,     // NV21_adreno_tiled
    HAL_PIXEL_FORMAT_YCrCb_422_SP       = 0x23,     // NV61
    HAL_PIXEL_FORMAT_YCrCb_422_P        = 0x24,     // YV12 (_adreno)
};

Source: hardware.h (lines 121-148)

If you were to compare the values with the ones defined in PixelFormat.java, you’ll find they add up quite nicely (as they should). It also shows the meaning of the mysterious 5, which is BGRA_8888; a variant of RGBA_8888.

By the way, you may want to try determining the pixel format details for this integer value using the aforementioned getPixelFormatInfo(...) method by passing in 5 as identifier. It’ll be interesting to see what gets returned. I’d expect it to show values matching the BGRA_8888 definition, and hence similar to those given in the linked discussion on the Motorola board.