Whenever we need to rotate and resize a huge image file on Android (no bitmap allocated yet), the usual steps would be to first load the image into a resized bitmap, then do the rotation on another newly created bitmap.
If I do the rotation first I'll probably end with the dreaded OutOfMemoryError. This is quite logical and I'm OK with that.
Problem is, both approaches include having two bitmaps at once in memory at some point, and I'm on a tight memory budget here, even after implementing bitmap scaling as the official docs say (https://developer.android.com/topic/performance/graphics/load-bitmap). A typical implementation looks like this:
Bitmap bitmapResized = resizeBitmap(fSource, nTargetWidth, nTargetHeight);
Bitmap bitmapRotated = rotateBitmap(bitmapResized, nOrientation);
[recycle both bitmaps here]
Is there any way to do both steps at once in a memory lightweight fashion?
I have read about renderscript but I wasn't able to find code that does not take an already allocated bitmap.
Related
I have a drawing-board App and there's an "export image" function. I hope the exported image size can be as large as users want. The exporting steps are:
create a bitmap;
applying some transformation matrices;
create a canvas on that bitmap and draw something on it.
compress the bitmap and save to file
When using Java Bitmap.createBitmap, if the created bitmap is so large and the required memory reaches Android VM heap size limit, an OutOfMemoryError encountered.
To avoid the OOM error I'm considering to create a bitmap with native-allocated pixel data in JNI, and used the bitmap as a reference in Java. But so far I have no idea about how to achieve this at all even after I searched a lot.
Or if I can't do this, is there another way to draw canvas to a probably very large bitmap without OOM errors?
Thanks for any help!
If the end result is a file, you don't need to use Bitmap at all. Use a C or C++ image library and do everything natively. It'll also be MUCH faster (in fact Android decodes bitmap in C already, it's too slow in Java and pointers make it easier).
How big is the bitmap anyway? Remember that a bmp requires 4*width*height bytes in memory. There's a limit to how big of one you can create even in C based memory.
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.
For my application I need to load a bitmap which sometimes can be really large. I'm getting OutOfMemory errors even on devices like galaxy S2. I searched around and found that I need to recycle the bitmap.
Previously I was loading the bitmap with BitmapFactory, creating a new scaled bitmap, and creating a bitmapdrawable all in one line. By doing this am I loading two bitmaps into memory? Should I create the initial bitmap and then recycle it after creating the scaled bitmap?
If the activity will be launched frequently should I load the bitmap once to a static field or should I recycle and recreate every time?
Thanks
Split the process into multiple steps. If you are measuring the bitmap against the available screen space and then loading a scaled bitmap, you can do the first step without loading the bitmap into memory using BitmapFactory.Options.inJustDecodeBounds. This will give you a Bitmap object without the pixel data but with the width and height properties. Then use that to decode your scaled bitmap using BitmapFactory.Options.inSampleSize.
Google these terms and you'll find tons of sample code doing just this. And yes, don't forget to recycle when you're done with a Bitmap.
https://www.google.com/#q=BitmapFactory+Options+inJustDecodeBounds+inSampleSize
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.
I am trying to decode a bitmap with pixel size 1024*683 with the api
decodefile(filepath) but process runs out of memory while decoding the
image.
I need the bitmap object for this image at one go without any scaling
as i have to work with NDK reading the pixel values using this bitmap.
Therefore any scaling or sampling method can't be applied in my case.
I wonder how come this is possible that just decoding a file with
such size would need any in-around method. There is enough heap size
available for this process.
Your opinion and perspective in this matter will be appreciated.
Thanks
Nawab
I faced the same problem when I had memory leaks in one of my activities. There were not only view leaks, but bitmap leaks too. And memory consumed by bitmaps is not taken into account when DDMS shows free heap space.