1

I have an application that displays lots of images, and images can be of varying size up to full screen dimensions of device. The images are all downloaded, and I use imagemagick to reduce colors of image to compress the file size, while keeping dimensions the same, to reduce download time. The reduced color space is fine for my application.

The problem is that when I load the image into a Bitmap in android the file size is much larger because of androids Bitmap config of ARGB_8888, I do need the ALPHA channel. Since ARGB_4444 is deprecated and had performance issues I am not using that. I am wondering if there is any other way to reduce the memory footprint of the loaded Bitmap while keeping the dimensions the same as the original?

---- Update ---

After discussions here and lots of other searching/reading it does not appear that there is a straight forward way do this. I could use ARGB_4444 which stores each pixel as 2 bytes, rather than 4 bytes per pixel. The problem there is that ARGB_4444 is deprecated, and I try not to use deprecated parts of the API for obvious reasons. Android recommends use of ARGB_8888 which is the default, since I need alpha I have to use that. Since there are many applications that do not need such a complex color space it would be nice to see ARGB_4444 or something similar become part of the supported API.

esse
  • 5,429
  • 3
  • 19
  • 20

2 Answers2

4

If you don't need alfa (transparency) you can use:

Bitmap.Config.RGB_565

which uses 2 bytes per pixel, instead of 4, reducing size by half.

You should also look at BitmapFactory.Options:

inSampleSize
inScaled

These values correctly set for your requirements, may have a very positive effect on Bitmap memory requirements.

Regards.

Luis
  • 11,978
  • 3
  • 27
  • 35
  • I do need alpha (edited question) and my understanding of the Options you mentioned is that they will change the dimensions of the image. I actually do some scaling to match different device screens, but my question is still is there a way of reducing memory footprint while keeping dimension. – esse Dec 02 '12 at 20:50
  • It will be a trade off. `inScale` adjusts the `Bitmap`density to match the device. This is done only once and may result in a bigger bitmap for big screens/densities. If you have an image that has lower density then the screen, you may decode the bitmap with original density, and request to scale it at draw time. If Image needs a constant redraw, this will will be slower, hence the trade off. – Luis Dec 02 '12 at 21:23
  • Ya, I don't think there is a nice way to do what I want. I already do scaling to match the device screen resolution/density. But since I don't need ARGB_8888, because my small color space, I would rather not have to use the ARGB_8888 size for the Bitmap. This would result in me being able to load many more images into memory, which is more important to the application I have. – esse Dec 02 '12 at 21:32
0

Read a similar answer I posted here

Basically, bitmap recycle is required for Pre honeycomb devices to reduce memory usage

Community
  • 1
  • 1
Kiran Kumar
  • 1,192
  • 8
  • 10