Develop Reference

Android ImageView.setImage* vs. BitmapFactory.decode*

I'm currently facing several performance issues (out-of-memory) when handling a vast amount of bitmaps. As this is just a problem that can be fixed I'm wondering if anybody can explain me the difference in using the following methods.
If I only want to load an image into an ImageView I usually use:
imageView.setImageDrawable(getResources.getDrawable(R.drawable.id));
If I want to sample the drawable beforehand I usually use (here without sampling):
Bitmap bm = BitmapFactory.decodeResource(getResources(), R.drawable.id);
imageView.setImageBitmap(bm);
My question is related to performance optimisation. I'm wondering whether it is better to provide as many drawables as possible using the different drawable folders (so these drawables nearly fit the required resolution for the different devices) or if it is better to sample high-quality drawables? What is setImageDrawable doing internally? Does it decode the resources using the BitmapFactory, just without sampling? There seems to be a trade-off between the actual size of the app and the cpu- and memory-load during runtime.

if you're concerned about apk size, then having as many drawables as possible is not the ideal way to go. but dont forget, when you decode a bitmap, you can pass a sample size so it will scale down to the screen size and only give you the pixels you need, so older phones with smaller screens wont need to decode 8mp images.
check BitmapFactory.Options and here

Why does decoding bitmap with inBitmap always get java.lang.IllegalArgumentException: P ro blem decoding into existing bitmap

I am using inBitmap to load bitmap on android3+. But I always get java.lang.IllegalArgumentException: Problem decoding into existing bitmap.
In LruCache's entryMoved() function: I use reusableBitmaps.add(new SoftReference<Bitmap>(oldValue.getBitmap())); to keep bitmap.
and next time to load bitmap:
I use iterator on reusableBitmaps to find which one I can use for inBitmap,
I use iterator to find which one, just like managing memory on official developer website.
But unfortunately, failed always, logcat shows java.lang.IllegalArgumentException: Problem decoding into existing bitmap.
Anyone can give me a sample or tutorial?

I fixed this using:
options.inSampleSize = 1;
This is a tip from the video mentioned at the second comment to the question.

Bitmaps are immutable as far as I can reason from the Bitmap api. The Bitmap class does not have a public constructor. To create one you have to specify the width and the height of the bitmap to one of the createBitmap methods.. So you cannot reuse a Bitmap instance.
But, just in case I am wrong, I guess the error will still be related with the fact that the bitmap holds the width and the height of the bitmap, which determines the size of the byte buffer used to decode the bitmap.
If you're decoding images of different resolutions into the same bitmap, this will most probably cause errors.
To troubleshoot try your very own same code to decode images of exactly the same width and exactly the same height. If your error goes away then my theory is correct and you need to cater for image sizes when it comes to reusable Bitmaps.
I am also interested in the result, so if you can post your findings that's be great.
Cheers

BitmapFactory.decodeFileDescriptor

I need to upload a large image. The right way would be to use BitmapFactory.decodeFileDescriptor with inSampleSize options. But the problem, that the image is still to big to fit in memory on some devices. Is there a way, to somehow recieve an InputStream of a scaled image instead of bitmap?
Or can you suggest any other way?

Always the best place to start is the provided documentation.. they provide sample code of how to Displaying Bitmaps Efficiently
start from here, it'll help you Load Large Bitmaps Efficiently

OutOfMemoryError when opening lot of little pictures [duplicate]

This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
OutOfMemoryError: bitmap size exceeds VM budget :- Android
In my application I load some little Bitmap(between 2k and 300k) that I affect to ImageViews, during the first launch of my App it works fine but when I quit it and relaunch it, I always have the OutOfMemoryError during a Bitmap creation.
Could somebody tell me why?

The problem is because your bitmap's size is too large than the VM can handle. For example from your code I can see that you are trying to paste an Image into imageView which you are capturing using Camera. So normally the camera images will be too large in size which will rise this error obviously. So as others have suggested, you have to compress your image either by sampling it or convert your image into smaller resolution. For example if your imageView is 100x100 in width and height, you can create a scaled bitmap so that your imageView gets filled exactly. You can do this for that,
Bitmap newImage = Bitmap.createScaledBitmap(bm, 350, 300,true);
And you have to recycle your bitmap and null your bitmap like this,
Bitmap bmap.recycle();
Bitmap bmap=null;

You should use bitmap.recycle() manually when you leave your activity.
Please refer to http://developer.android.com/reference/android/graphics/Bitmap.html#recycle()

I really doubt you have to use bitmap.recycle() if you null your references, allowing GC (but please prove me wrong).
I'd say it's more likely your bitmaps are too large, possibly aggravated by long lived Context references or somesuch.

OutOfMemory error while joining large images

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.