16位图像和android处理

时间:2010-08-21 19:53:19

标签: android opengl-es bitmap imageview

我是否正确地说16位图像将被解码并且绘制得比24位或32位更快?我知道文件大小会更小但是如果实际绘制的位图实际上比转换它们的努力更快。如果速度更快,我将如何保存16位jpeg文件?我只在photoshop中找到一个选项来保存一个16位的位图...这是54 MB。

2 个答案:

答案 0 :(得分:3)

这取决于。如果你的屏幕(以及绘制它的表面)是16位,它可以更快;但是,如果它们是32位,则32位位图可能更快。

然而,如果你在资源方面看这个 - 这意味着jpeg或png图像 - 说它们是“16位”或“32位”是没有意义的。 JPEG是一种颜色表示,通常你可以扩展到32位,虽然你也可以解压缩到16位(并且可能想要抖动,同时这样做看起来不错)。 PNG可以存储很多表示形式,具体取决于图像,并且通常选择最佳的表示形式。此外,在打包过程中,aapt会遍历所有PNG图像并将其重新压缩成尽可能小的最终图像,因此如果可以的话甚至可以使用调色板表示。

因此,如何存储图像并不重要;重要的是在运行时解压缩时创建的位图。这里有一些一般规则:

  • 如果图像有alpha,则需要将其解压缩为完整的32位。
  • 如果帧缓冲区和表面是32位,则应将图像解压缩为32位。
  • 如果图像没有alpha,则可能是888(32位)或565(16位)。挑选使用的是......棘手的。

从历史上看,我们在平台上使用的设备有16位屏幕,所以我们不得不处理它的复杂性。主要问题是平衡内存使用与渲染性能和质量之间的平衡。对于内存使用和渲染性能,16位是最好的...但是,对于许多图像,如果图像没有抖动,将会出现色带。

在哪里做抖动也很棘手:理想情况下,你可以将其作为生成原始图像的一部分,但这限制了你可以用它做什么(没有缩放,这意味着没有使用9补丁)。另一方面,您可以在渲染时执行此操作,但这意味着您需要将图像加载为32位并在每次绘制到屏幕时抖动。这提供了最大的灵活性,但具有更多的内存和性能影响。

现在在实践中,这实际上最终成为平台的一个罕见问题 - 因为几乎所有用作9补丁等的图像也具有透明性,它们无论如何都需要加载为32位,所以它是渲染时抖动并不算太大。

这一切都可以做到:

  • 如果您的图片具有透明度,请不要担心,无论如何都会加载32位。
  • 如果您的图片没有透明度,则需要:
    • 决定是否抖动原始图像。这将在16位屏幕上提供更好的质量(您将比性能关键渲染代码做更好的抖动),但不会充分利用32位屏幕。
    • 让平台决定做什么。这将为16位和32位屏幕提供良好的结果,但您不希望缩放图像。
    • 自己加载图像,并明确控制API以决定使用何种格式以及何时(或是否)抖动。

答案 1 :(得分:0)

我希望你的意思是16位RGB 565格式,是的它应该比24位RGB 888或32位RGB 8888格式更快。您在photoshop中看到的内容可能与RGB 565不同,但RGB每个分量为16位,每个像素加倍RGB,每个像素为8位。

AFAIK JPEG不支持16位格式(每像素为565或16位)。