CODEWITHSUNDEEP
androidcachingbitmapheap-memory
Hyndrix
Hyndrix

Reputation: 4452

Android VM heap strategies for big images

I am manipulating relative large images, about 5MP and sometimes even more. I need two copies of the images in memory for manipulation. Now, the loaded images consume a lot of memory, more than available by the default Android heap which is 16MB respectively 24MB which results in the following error:

11-20 18:02:28.984: E/AndroidRuntime(7334): java.lang.OutOfMemoryError: bitmap size exceeds VM budget

I need full resolution, thus downscaling while loading the images does not help. What's the best solution to get over this problem? Are there built-in methods to dynamically load only chunks of bitmaps from storage? And can someone give me some hints how I can overcome the memory problem, e.g. by using specific caching strategies?

Regards,

Upvotes: 3

Views: 1494

Answers (2)

eSniff
eSniff

Reputation: 5905

You should watch this video on memory management: http://www.youtube.com/watch?v=_CruQY55HOk At about 6 mins into it he covers the LargeHeap manifest option added to HoneyComb.

Upvotes: 1

Kevin Galligan
Kevin Galligan

Reputation: 17332

You can allocate more memory in the ndk. You'd have to write native code to manipulate the images, or you'd have to figure out a way to allocate the image memory in native, then pass it back to Java.

Bitmap/Canvas use and the NDK

Another option might be to load a single image into memory, and break it up into chunks for processing. Save those chunks out to the file system. So, say you 2 large images. You load the first image, break it into 4 parts, save them, load the second, break it into 4 parts, save those, then load part #1 for each image, and do your thing. That implies you know that neither individual image is larger than the heap max, and that what you need to do is (basically) pixel level and doesn't need access to surrounding pixel data (you'll run into trouble at the edges if you need neighbor pixel info).

Without downsampling, splitting, or ndk, I don't know how you'd get more image data into memory. Perhaps lowering the color info. We do this in a product. Represent each pixel as 16 bits rather than 24 or 32. Our product is functional rather than "pretty", so the loss of color info wasn't a big deal.

Upvotes: 1

Related Questions