困惑的PixelFormat

本文介绍了困惑的PixelFormat的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！

问题描述

我感到困惑的PixelFormat 在Android上。

我的设备是摩托罗拉Defy。

我有两个问题：

在Android 2.3的 getWindowManager（）getDefaultDisplay（）getPixelFormat（）返回 4 什么代表的。据我知道我的设备具有的 16M 的颜色，这意味着3（或4 alpha通道）每像素字节：

但 RGB_565 格式有2个字节（16位）每像素，什么代表的 65K 的颜色：

那么，为什么 getPixelFormat（）不返回3（或4类似RGBA）格式的每像素字节？难道是显示驱动程序问题还是什么？我可以设置的PixelFormat 来的（或模拟）？

在的Android 4.1（自定义ROM）， getPixelFormat（）返回 5 。但这个值是未公开的。它代表什么？实际上，在这种情况下，效果是一样的恒 4 。但是，从这个讨论我发现， 5 表示 RGBA_8888 （但没有证据证明这种说法）。所以，我怎么能计算出的真正的设备屏幕的格式？此外，我发现了一个中国的设备上Android 2.2系统，还具有的PixelFormat 5 ，但真正的格式是 4 （作为我的摩托罗拉）。

我GOOGLE了这些问题，并没有发现什么。我发现的唯一的事情是，nexus 7还具有5格式。

更新：

我找到方法 getWindow （）.setFormat（） 但它实际上并没有改变主要的像素格式。

解决方案

我就加我的两分钱的讨论，但我必须承认事先，我无法找到确凿你所有的问题。

我对你在问究竟在这里有点摸不着头脑。 getPixelFormat的返回值（）仅仅是一个整数，它提供了一种识别有效像素格式的一种方式;它并不意味着重新present压制成数的任何数据（例如，与 MeasureSpec ）。不幸的是，我没有为什么比你预期不同的是返回的解释。我最好的猜测是，它要么是由于操作系统的决定，因为似乎没有被从硬件的角度来看的限制，或者，在本机实现中定义的常量不匹配那些在Java中。你得到后面的事实 4 的像素格式然后将并不一定意味着它真的RGB_565，如果摩托罗拉搞砸的定义。

在一个侧面说明：其实我已经遇到之前在Android的错位常量定义，虽然我目前还不能记得在什么地方...

只是为了确认，它可能是值得打印出像素格式细节在运行时。如果有确实是使用Java 的PixelFormat 价值，但不匹配定义的本地常数，你可能揭示了真正的格式这种方式。使用 getPixelFormatInfo（INT格式的PixelFormat资讯） 方法，简单地代表从本机实现获取的实际值。

如前所述，有时在本地code定义的常量不匹配那些在Java中，或者是没有定义的。这可能是这样的情况。你必须做一些挖掘，以找出它重新presents，但它是相当简单：

  / **
 *像素格式定义
 * /

枚举{
    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的范围内不可用* /
    HAL_PIXEL_FORMAT_YCbCr_422_SP = 0×10，// NV16
    HAL_PIXEL_FORMAT_YCrCb_420_SP = 0×11，// NV21（_adreno）
    HAL_PIXEL_FORMAT_YCbCr_422_P = 0×12，// IYUV
    HAL_PIXEL_FORMAT_YCbCr_420_P = 0x13，// YUV9
    HAL_PIXEL_FORMAT_YCbCr_422_I = 0×14，// YUY2（_adreno）
    / * 0x15保留* /
    HAL_PIXEL_FORMAT_CbYCrY_422_I =为0x16，// UYVY（_adreno）
    / * 0x17已预留* /
    / *为0x18  -  0x1F的范围内不可用* /
    HAL_PIXEL_FORMAT_YCbCr_420_SP_TILED = 0x20的，// NV12_adreno_tiled
    HAL_PIXEL_FORMAT_YCbCr_420_SP = 0×21，// 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）
};

<一个href="http://nv-tegra.nvidia.com/gitweb/?p=android/platform/hardware/libhardware.git;a=blob;f=include/hardware/hardware.h;h=d316ccf1828d7eb20cdd170fd702ae418b12d852;hb=373a9c6efebc97ade940dc5996f24992cda450c7"相对=nofollow>来源： hardware.h （行121-148）

如果你比较与 PixelFormat.java 中定义的值，你会发现，他们加起来得相当好（因为他们应该）。这也说明意义的神秘 5 ，这是BGRA_8888; RGBA_8888的变体。

顺便说一句，你可能会想尝试通过传递<$ c。使用上述 getPixelFormatInfo（...）方法确定此整数像素格式的详细信息$ C> 5 的标识符。这将是有趣的，看看有什么被退回。我期望它显示值匹配BGRA_8888定义，因此类似于在摩托罗拉板链接讨论给出。

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:

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

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.

解决方案

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.

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.

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.

这篇关于困惑的PixelFormat的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！