I know there is a lot of discussion about android bitmap images out of memory but I was wondering if someone could explain it to me..
Currently in my app I have an activity which lists image thumbnail (low quality) and when I click an image it opens a new activity to view the image full screen. In my 2nd activity class I have:
BitmapFactory.Options options = new BitmapFactory.Options();
options.inSampleSize = 1;
bm = BitmapFactory.decodeFile(myImagePath, options);
I then put this into an ImageView to display it. This works and displays my image to its full quality. However if i click back and then click to see that image again (and repeat this 6 times) .. on the 6th time opening the image (activity2) I get an out of memory error saying Heap size=6919KB, Allocated=3125KB, Bitmap Size = 25848KB!
How is bitmap size that big? I assumed it may be creating new instances all the time so I then decided to put a method in my 2nd activity for when the back key is pressed..and in this method I set my bitmap=null and also did System.gc() to clear the garbage collector BUT this did not fix the problem. I still get an out of memory error on the 6th time of clicking on the thumbnail to view the image in full resolution
Can anyone explain why? Thanks
There is some great information from android that explains it all in detail, and how to overcome this problem here.
Each pixel is 4 Bytes. 6M Pixel = 24MBs
One photo can use up all the Memory.
Bitmaps take up a lot of memory, especially for rich images like photographs. For example, the camera on the Galaxy Nexus takes photos up to 2592x1936 pixels (5 megapixels). If the bitmap configuration used is ARGB_8888 (the default from the Android 2.3 onward) then loading this image into memory takes about 19MB of memory (2592*1936*4 bytes), immediately exhausting the per-app limit on some devices.
Again I point you to this great link I found from another SO Question that has tutorials of how to properly over come the problem.
inSample size should be set so that the image is scaled to the size of the display area (1 = full size) unless there is some reason you think you need all the bits of the image, so 2 would = 1/2 scale 4 1/4 scale etc.
Also try bm.recycle() when you are finished with the bitmap before using =null
Update
Look at the second answer what does recycle do unless you have already tried that and it didn't work. I have done similar things with loading images and never run out of memory, that's not proof that it will work for you, but it's a best practice as far as I can tell.
Related
My app takes an image using the device camera, then opens it so the user can perform some processing. To do this I check the image orientation and rotate it if necessary, which I do like this:
Bitmap image = MediaStore.Images.Media.getBitmap(this.getContentResolver(), lastTaken);
int rotation = getCameraPhotoOrientation(filePath);
if (0 < rotation)
{
Matrix mx = new Matrix();
mx.setRotate((float) rotation);
image = Bitmap.createBitmap(image, 0, 0, image.getWidth(), image.getHeight(), mx, true);
}
This code works on most devices, however on one of the older test devices I have been using, it causes an OutOfMemoryException when the image is rotated, presumably because it is trying to hold two copies of the image in memory.
How can I avoid this?
If there isn't an easy way to prevent the problem at this point in the process, is there a way that I can test how much memory I have available and limit the image resolution the camera uses to one that will leave enough room for this operation? I'm already specifying resolution, so it is really a question of how I can compare the image size and available memory to figure out what resolution would be safe. My one constraint is that the changes the user makes have to be on the original image, so editing a smaller copy of the image won't cut it, unless there is an easy way to reflect those changes on the stored version. Consequently downsizing the image to something that can be supported in memory wouldn't be a disaster by any means.
What is the size of your image? Did you check for possible memory leaks in the App?
Anyways, one way is, you can try to reuse the memory allocated to the first Bitmap after a new second Bitmap content is created.
As per Android docs here - https://developer.android.com/topic/performance/graphics/manage-memory ,
Android 3.0 (API level 11) introduces the
BitmapFactory.Options.inBitmap field. If this option is set, decode
methods that take the Options object will attempt to reuse an existing
bitmap when loading content. This means that the bitmap's memory is
reused, resulting in improved performance, and removing both memory
allocation and de-allocation.
You can set your Bitmap image to be recycled when a new Bitmap is created.
I couldn't find a way to figure out the amount of memory available and how much I would need, but after finding some other questions on this topic I found that the best solution for me was to enable the largeHeap element in the application manifest - that resolved the crash for me, although it didn't answer the question and after further reading I suspect there is no satisfactory way to do this as things stand.
I'm taking whole screenshot of a WebView and display the bitmap on an ImageView. The bitmap can be 7 screen height. (E.g. 1440x14000 px)
I'm frequently face with
OutOfMemoryError.
I've seen this
This says that load a scaled down version into memory but I don't want to lose image quality. There are the same approaches on the web.
Is there any way to handle OutOfMemoryError without loading scaled down version?
The bitmap can be 7 screen height. (E.g. 1440x14000 px)
Note that this means that the user cannot see the whole image at once at full resolution.
I'm frequently face with OutOfMemoryError
On most devices, you will have a very difficult time loading an image that large, as you cannot get a single contiguous memory block that big.
This says that load a scaled down version into memory but I don't want to lose image quality
To some extent, you do not have much of a choice. If you want the user to see the full extent of the picture at once, the image has to be scaled to fit the screen.
Is there any way to handle OutOfMemoryError without loading scaled down version?
There are ImageView replacements that offer pan and zoom. Some of those, such as this one, handle loading in pieces of the image at a time, with whatever scaling is necessary for the current zoom level, to make it more likely that you will be able to show the user the entire image.
It is not a solution, of course, but I'm also not familiar with your exact needs, so maybe this may help you a little - you can try to play with bitmap options during decoding. Try to use Bitmap.Config.inPreferredConfig as RGB_565 - this will reduce size of your bitmap twice comparing to default ARGB_8888. But, of course, if you use complex images in your web page this may reduce their quality.
I have a gallery working in my app at the moment with about 8 pictures on it. Before i had a bug that use to make it crash because of overload Heap (something like that, not sure).
This was caused by my pictures being too big in file size, so i reduced them it worked. So my main question is How many picture can i actually put in to my app.
I was hoping to have about 5 screens (activities) with some scrolling pictures
I don't want to start changing my app if its just going to crash again
Also does anyone know how to add transitions when scrolling through pictures, for it too look fancy
Everything depends on the way you manage you pictures. To save the memory (and increase the number of images loaded) you should load a resized picture.
You can subsample picture while loading:
BitmapFactory.Options opts = new BitmapFactory.Options();
opts.inSampleSize = 2;
BitmapFactory.decodeResource(res, id, opts);
This will load a picture scaled 1/2 of it's original size (keep in mind that subsampling works only for power of 2 values). You can load the picture smaller than the area it will be displayed in and let ImageView to upscale it.
If your loaded image is still too large, you can scale it more with Bitmap.createScaledBitmap().
You should be aware that pre-Honeycomb Android doesn't recycle bitmaps like post-Honeycomb Android does. You should call Bitmap.recycle() as soon as the bitmap is not used anymore to clear the memory.
For image scrolling you can use ViewPager.
Further reading: http://developer.android.com/training/displaying-bitmaps/index.html
There is no strict limit on the number of pictures you can include in your app. See the stock Gallery app as an example, I consider myself a relatively light picture taker, but I still have hundreds of images in my Gallery. If you follow the Bitmap best practices you shouldn't run into any memory issues, and you should be able to include as many images as you want.
I'm trying to write simple application where I can swipe between photos (like that standard gallery app on each device). Standard one demonstrates impressive performance - it displays next photo instantly while takes only about 15 MB of memory. It seems like it keeps next and previous images in memory so it doesn't have delay due to loading them from sd-card. I think that if the application keeps at least 3 Bitmap objects of such size in memory, it will take much more than 15 MB. So how it works? Don't use Bitmap or what? Thank you.
Remember that the bitmap on the screen might not be the size of your original file.
Take a 720p screen for example, a 4096*3072 picture will be decoded and re-sized to screen size.
Even the APP might be using ARGB8888 format to display a bitmap, the memory size is 1280*720*4 = 3686400 bytes, that is about 3.5M.
And if we use RGB565 format, the size will be half small then.
What's more, not all the picture is 'full screen'.
I am joining two images using the code below but it throws an OutOfMemory error my images are around 1MB each.
private Bitmap overlayMark(String first, String second)
{
Bitmap bmp1, bmp2;
bmp1 = BitmapFactory.decodeFile(first);
bmp2 = BitmapFactory.decodeFile(second);
if (bmp1 == null || bmp2 == null)
return bmp1;
int height = bmp1.getHeight();
if (height < bmp2.getHeight())
height = bmp2.getHeight();
Bitmap bmOverlay = Bitmap.createBitmap(bmp1.getWidth() + bmp2.getWidth(), height,
Bitmap.Config.ARGB_8888);// Out of memory
Canvas canvas = new Canvas(bmOverlay);
canvas.drawBitmap(bmp1, 0, 0, null);
canvas.drawBitmap(bmp2, bmp1.getWidth(), 0, null);
bmp1.recycle();
bmp2.recycle();
return bmOverlay;
}
Update: I tried below two answers but it still not allwoing me to create bitmap of such big size the problem is that the resultant bitmap is too large in size around 2400x3200 so its going out of memory.
How can I join large images without running out of memory?
Without loading the image into memory, you CAN get the size of the image, using inJustDecodeBounds. The Bitmap returns null, but all the parameters are set. You can scale down the image accordingly.
If your JPEG images are 1 MiB each, conversion to a BMP will take a lot of memory indeed. You can easily calculate its BMP equivalent by the dimensions of the image. Conversion of such a large image is expected to crash indeed. Android limits its apps to 16 MiB VM only.
Also use RGB_565 instead of ARGB_8888.
So your only solution is:
(a) To use BitmapFactory.Options.inSampleSize to scale down the image
or
(b) Use Android NDK where the 16 MiB limit isn't there.
I use this simple rule of the thumb:
the heavy lifting (both memory/CPU) is done on the server.
So write some servlet that takes the image, resizes it to a specified dimension (probably reduces the pixel depth too) and returns the result.
Piece of cake and it works on any mobile device you need.
Good luck!
I think a solution sort of like Sumon suggests might work.
Figure out the size of the final
image based on what will fit on the
screen.
Get the size of the first image using
the inJustDecodeBounds technique.
Figure out the size of the first
image in the final image. Calculate
re-sizing parameters.
Resize image, loading into memory.
Write resized image back to disk.
Recycle the bitmap. (This will help
when resizing the 2nd image)
Repeat for the second image, only you
can skip the writing to disk part.
Load first image.
If you only need to display, then just do that. If not then you can combine into a single bitmap at this point and write to disk. If this is the case, it may be difficult because you wil have essentially 2x the screen size in memory. In that case I would recommend resizing smaller. If you can't go smaller, then you will have to go the NDK route, thought I'm not sure how much that will help. Here's an amusing intro to the NDK and JNI. Finally, I would highly recommend developing this using a phone running Android 2.3+ since its use of heap-allocated bitmaps will make debugging much easier. More about those here.
It's not necessary that the space taken by in-memory representation of bitmaps correspond closely with file size. So even if you have 3mb memory available to jvm, you might still get OutOfMemoryException.
Your code is creating three in-memory images simultaneously. If you can find the size of both images without reading the complete files, you can modify the code in a way to have only one of the source images in memory at a time. If even that doesn't prove to be sufficient you might need some sort of streaming method of reading the images.
you may get some idea from here.
Are you trying to display this super large image or are you just trying to save it?
If your trying to display it. Cut the images into tiles. Then only display the tiles that are being viewed. If the user zooms out you need to reduce the size of the bitmap before showing the whole thing.
If your trying to save it, try saving it in sections to the same file by cutting the image up.
Loading 2 1m files in memory then creating a 2m file leaves you with 4M in memory for your images alone. Dynamically loading and unloading the memory solves this issue similar to tiles on Google maps or dynamic zooming in other map oriented solutions.
If you need to return that huge 2400x3200 bitmap as your result, there is no way to actually realize this goal. The reason is that 2400*3200*4 bytes ~ 30 Mb! How can you hope to implement this method, when even you can't even fit the return value into your limited heap space (ie 16Mb)?
And even if you used 16-bit color, it would still fail because you would end up using about 15MB, which would not leave you enough space for the language run time.