Develop Reference

Why does Android BitmapFactory.decodeFile() want 4x the memory needed?

I have an 8MB png and when I try to load it into an Android ImageView I get an OutOfMemoryError that says it tried to allocate 32MB of memory and failed.
I'm working on changing the code to downsample the image to avoid using too much memory to avoid most of these problems, so I'm not looking for answers about downsampling. I'm trying to understand why the memory needs of the image are higher than the file size would imply.
Why is Android trying to allocate 4x the memory when loading the png?
I've set my options to tell it not to scale for pixel density:
BitmapFactory.Options options = new BitmapFactory.Options();
options.inPreferredConfig = Bitmap.Config.ARGB_8888;
options.inScaled = false;

It is 2848 x 4209 pixels
At the 4 bytes/pixel rate for ARGB_8888, that will be 47,948,928 bytes as a Bitmap.
The on-disk size of images represents a red herring. The major file formats (particularly PNG and JPEG) are compressed as files. That does not matter. What matters is the resolution and bit depth of the desired decoded image.
Also note that your image is bigger than the display resolution of most Android devices. Depending on your use case, you may wish to consider widgets like this one that can load and display portions of the image at a time.

how to reduce the bitmap memory usage byte count but keep its dimensions

Searched and only find solutions for scale the bitmap to reduce its dimensions and size. But I am looking for a way to reduce the bitmap's memory byte count and don't change its dimension.
The images are from remote sources, they are not in our control. , after save the images to device locally, they will be shown as thumbnail later. Noticed it frequently throws OOM exception. The first step was to scale down the bitmap to a smaller dimensions when loading from the file (such as 500x500, or 300x300), here has some suggestions, which helps a little bit.
A closer look find the scale downed bitmap may still have large byte count (from a few hundreds k to over one meg).
Since for this case the bitmap with lower resolution in memory should be ok, so is there a way it can keep the bitmap's dimensions but reduce it memory byte count?
Thanks!

You can read it in as RGB_565 instead of ARGB_8888, to reduce the bit depth from 4 bytes/pixel to 2 bytes/pixel. However, that's all you can do, as the memory footprint of a Bitmap is the number of pixels times the bit depth per pixel.

Android Bitmap loading out of memory error Galaxy S3 WXGA

I would be very grateful if someone could confirm that I have solved the below problem correctly or if there is an alternative solution?
I have an app that loads a large image (e.g. 800*1720 pixels) into memory and displays it in a scrollview. The image is a floor plans for a museum and I wanted a simple map like experience of scrolling and zooming. The image loaded fine on older devices, but caused an out of memory error on a Samsung Galaxy S3.
Looking at the LogCat messages it turned out that in creaing the bitmap 22MB was being allocated for the bitmap instead of 800*1720*4 = 5.5MB. Essentially 4x as much memory was being allocated as required by other devices and pushing the memory usage over the 50MB heap size.
The recommended solution to this problem is to use the BitmapFactory.Options.inSampleSize option to reduce the resolution of the image loaded and have it require less memory. However, this reduces the quality of the image, and I actually want to display it at it's full size in the original quality as works fine on older devices.
After much head scratching I concluded that the issue was that the pixel density on the S3's WXGA screens is 2.0 and thus for each pixel in the image, the bitmap was actually allocating 4 pixels. With a bit of trial and error I discovered I could prevent this happening by setting options.inScaled = false;
http://developer.android.com/reference/android/graphics/BitmapFactory.Options.html#inScaled
On the way, I also realised that I could cut my memory usage in half to 2.7MB by using a lower fidelity colour depth of 2 pixels instead of 4 pixels by setting options.inPreferredConfig = Bitmap.Config.RGB_565;. For my floorpans this didn't effect the visible image quality.
The final code was thus:
String uri = "drawable/floorplan";
int imageResource = getResources().getIdentifier(uri, null, getPackageName());
BitmapFactory.Options options = new BitmapFactory.Options();
options.inPreferredConfig = Bitmap.Config.RGB_565;
options.inScaled = false;
Bitmap bm = BitmapFactory.decodeResource(getResources(), imageResource, options);
IVfloorplan.setImageBitmap(bm);
When displaying this bitmap you need to scale it back up. To work out the scaling you can obtain the pixel density from:
float density = getResources().getDisplayMetrics().density;
I reduced memory usage for the bitmap from 22MB to 2.7MB, which in a 50MB heap is significant.

The screen of the S3 has a really high res, so it's quite understandable. Also, if the image is in the drawable folder, it could be getting upscaled automatically. There might be ways to turn that off. Even if your image size doesn't chance, the OS has to allocate a buffer to accommodate the image, also possibly one to accommodate showing it on the screen.
An alternative is using tiling, which is used in games like SNES games. This is also how they handled lots of graphics without running out of RAM. Evidence shows that this is how Google Maps has a map of Planet Earth. You basically chop up the large image into tiles and show the tiles on the screen as you are panned to them (of course, maybe 1 extra tile on each side).
Even though this is post-Honeycomb, where Google put in code to better manage Bitmap allocations, be careful with Bitmap allocation. It's more like a C program than a Java program, and it's a good idea to manage it like one. It's very easy to run out of heap space when using Bitmap objects in Android

bitmap size exceeds VM budget Error on Android

I'm loading 100 images from Asset folder to an array object. The pictures are quite small (png ~20k each), and im using this code do to it, and to prevent memory leak & optimized performances:
in a loop:
// create resized bitmap from asset resource
InputStream istr = assetManager.open(pics[i]);
Bitmap b = BitmapFactory.decodeStream(istr);
b = Bitmap.createScaledBitmap(b, 240, 240, true);
where pics[i] is a list of filenames which sits in my Asset folder.
The code works for me, but i still receive from time to time Errors from users (i see it on Developer Console errors):
java.lang.OutOfMemoryError: bitmap size exceeds VM budget
at android.graphics.Bitmap.nativeCreate(Native Method)
at android.graphics.Bitmap.createBitmap(Bitmap.java:468)
at android.graphics.Bitmap.createBitmap(Bitmap.java:435)
at android.graphics.Bitmap.createScaledBitmap(Bitmap.java:340)
Is there anything i can do to improve it? or this is Android's world, we can never deliever a perfect application?

Of course you can improve something: Don't load too much pictures into the memory at the same time (or reduce their size). Some devices don't have much memory available. Your device may have a higher heap limit than some of your customers phones. Therefore it crashes for them when it works for you (see this video for some heap limits [at 4:44]).
You may get the available heap size via ActivityManager.getMemoryClass().
To improve this, test which pictures you need right now (which are displayed) and are which not. Load only the required ones and recycle the bitmaps you don't need anymore.
Also try using the BitmapFactory.decodeResource() and BitmapFactory.Options.inSampleSize. This allows you to load images at a lower resolution directly without loading them at the full size and then resizing them as you did here.

Bitmaps aren't compressed so they are stored in width * height * 4 bytes. It means that every image uses about 225 KB of memory. 100 images require about 22 MB of memory. The minimal heap size is 16 MB, but devices usually have 24+ MB heap. And this heap is used not only for data but also for activities, view and so on. That means you can't load 100 bitmaps of this size.

As a rule of thumb you should only ever need to show what the user can actually see. Holding anything else (graphics) in memory is just icing on the cake. This is why devices with higher resolution screens will have larger heap sizes available.
For example, on a 320x480 screen, you would only need as a minimum, 320x480x4=614400 (600kb).
Taking this concept into mind, you need to consider whether you need to hold 100 Bitmaps in memory. Is the user looking at 100 Bitmaps at one time? In that case you can reduce the quality of the images without degrading the user experience (there are only so many pixels on the screen). Is the user scrolling through 100 Bitmaps? Then dump and load images dynamically as appropriate (with a bit of caching for smoothness).
There is always a workaround.

How to choose optimum image size to not exceed VM budget?

In my app users choose images and program lets users to make changes on images. Since there are a lot of different android devices out there my program crashes on some of devices which less heap size. I want to calculate the best fit dimensions for user's phone so it won't crash because of VM budget. I have added a screenshot from "Picsay Pro" which is making exactly what i am looking for. I do know about the "BitmapFactory.Options" my only problem is to find a way to decide image dimensions which won't let crash the app because of VM budget.

Calculate the Free Space Remaining on the phone:
long freeMemory = (Runtime.getRuntime().maxMemory()) - (Debug.getNativeHeapAllocatedSize());
where,
Runtime.getRuntime().maxMemory() - returns the Total Heap Limit size (in Bytes).
Debug.getNativeHeapAllocatedSize() - returns the Amount of Data already used by your application (in Bytes).
Calculate the size of the Bitmap you are using by this formula,
long Bytes_allocated = (height of the Image) * (width of the Image) * 4;
Compare freeMemory and Bytes_allocated to select the appropiate size for your application.

I actually ended up compressing images on the phone for two reasons. One was upload speeds and another one was heap problems. You can try doing something similar, or at least post the stack trace!

Android outofmemory error bitmap size exceeds vm budget in 2.3.3
i think this compression technique could help

So far I've not found any reliable way to deal with image size vs available memory. The problem is the memory becomes fragmented very quickly, so that you could have 10 MB free, but no contiguous space for a 2 MB image. What is really needed is the size of the largest free space, but there doesn't appear to be any way to get this. Better would be a way to defragment memory, but no such function exist for this either.
Still if your available memory is less than the image, you can be sure you're going to crash if you attempt to use it, so it has some merit to at least check before you use it.
With late-2012 tablets now having 1920x1280 resolution, we now need 20MB of continuous memory for a single background image! It appears some of these tablets are now allowing heaps up to 256MB, but while tossing more VM space seemingly solves it, we really need a memory defragmenter or a way to reserve space.
There is one trick that might help if the image size is not scaled or modified, and each changed image is the same size AND you are limiting your app to Android 3.0+:
Options opt2 = new BitmapFactory.Options();
opt2.inBitmap = mBitmap; // reuse mBitmap to reduce out of memory errors
mBitmap = BitmapFactory.decodeResource(getResources(), myDrawable, opt2);
This will reuse the same memory area mBitmap for the image.