Develop Reference

How reduce the time than takes get a bitmap

I have a project on Android and iOS, there is a section where it shows a 360 view of a car, in iOS I just get the 60 images from internal storage that were previously downloaded from the internet, and these images are showed when the user starts to swipe the car to the right or to the left. And this process takes just 200ms to be ready to interact with the user.
But in Android I have to take first the 60 images and convert them in bitmaps, and then the process is similar to the iOS process. Nevertheless, this first process, convert all of them to bitmap takes about 3 seconds o more. I have read the process to show an image in Android in many sources of information and seems like is necessary use a bitmap for this task, so is possible to reduce the time to get all bitmaps?, or could I save a bitmap to avoid converting the PNG file again to a new bitmap when the users open the same view again?
The code that I'm using to convert png file to a bitmap object is the same that Android developers documentation recommend:
https://developer.android.com/topic/performance/graphics/load-bitmap
My source code for get bitmap is:
public static Bitmap decodeSampledBitmapFromFile(String filePath, int reqWidth, int reqHeight) {
// First decode with inJustDecodeBounds=true to check dimensions
final BitmapFactory.Options options = new BitmapFactory.Options();
options.inJustDecodeBounds = true;
BitmapFactory.decodeFile(filePath, options);
options.inSampleSize = 1;
// Decode bitmap with inSampleSize set
options.inJustDecodeBounds = false;
Bitmap bitmap =BitmapFactory.decodeFile(filePath, options);
Log.d("img360","bitmap res "+bitmap.getWidth()+ " h "+bitmap.getHeight());
return bitmap;
}
I'm really thankful for your help and support.

If you want to download images from Internet and display them on android
Just put an imageview and use picaso or glide library
It is faster and easier

Is this a correct way to get a bitmap's size before decoding it into memory?

I know I can use these ways to get the Bitmap's size:
bitmap.getAllocationByteCount(); //API 19
bitmap.getByteCount(); //API 12
bitmap.getRowBytes() * bitmap.getHeight(); //earlier version
But This all need a Bitmap object which mean I need to decode the bitmap into memory before, this may case OOM Exception. So I use this way to get the size before I can get Bitmap object:
BitmapFactory.Options options = new BitmapFactory.Options();
options.inJustDecodeBounds = true;
BitmapFactory.decodeFile(bitmapPath, options);
int picWidth = options.outWidth;
int picHeight = options.outHeight;
int size = 4 * picHeight * picWidth; //Byte
I think it cost 32 bits per pixel because Android decode bitmap use RGB_8888 default.
Is this a correct way or is there a better way to do this ?

You can select the bitmap configuration with BitmapFactory.Options.inPreferredConfig. This will allow you to specify a configuration where you know for sure how many bytes per pixel will be occupied by the Bitmap. I believe RGB_8888 is the default.
You can probably not 100% reliably prevent an OOM on a bitmap decode since you don't have a guarantee for a set amount of contiguous free space in memory for the allocation of the Bitmap. But you can certainly adjust your sample size and config to reduce the load.

Just create a File object with the path to the Bitmap. Then get file.length() to get the file size.
e.g. File bitmap = new File(pathToBitmap);
bitmap.length();
You'll have to put a try/catch clause as required.

Android bitmap size reduction not reducing memory

I'm new to android and am working on my first real app so i apologize if this question has been answered, or isn't detailed enough. I'm having the common OutOfMemoryError when loading bitmaps to my android app. I've searched around on stackoverflow and went through the google tutorial that describes how to use InSampleSize to reduce the memory for each bitmap.
When testing out the app to see how much memory I was saving by down scaling my bitmaps I noticed that the heap size was still growing at the same rate. I.E. When I use an InSampleSize = 8 vs not scaling the bitmap at all (or InSampleSize = 1) the heap grows the same for each.
I have tried printing the byteCount with:
myImage.getByteCount()
for both of the scaling SampleSizes listed above and they both have identical ByteCounts. Is this the expected behavior? Shouldn't the byte count be reduced since I'm downscaling images?
I was expecting to see the memory used to the bitmap reduced by a factor of 8 or so. Am I missing something, or is my understanding of image scaling incorrect? Thanks.
edit: After doing some testing I discovered that if I used createScaledBitmap the memory was reduced but it required me first inflating the original Bitmap then scaling. I'm assuming this is non-ideal since it requires that. I thought the first method would do this for me but according to my heap dumps it isn't.
Initial Code and heap dump:
private static Bitmap decodeSampledBitmap(Resources res, int resId, int width, int height
{
// First decode with inJustDecodeBounds=true to check dimensions
final BitmapFactory.Options options = new BitmapFactory.Options();
options.inJustDecodeBounds = true;
options.inPreferredConfig = Config.ARGB_8888;
BitmapFactory.decodeResource(res, resId, options);
// Calculate inSampleSize
options.inSampleSize = calculateInSampleSize(options, width, height);
// Decode bitmap with inSampleSize set
options.inJustDecodeBounds = false;
return BitmapFactory.decodeResource(res, resId, options);
}
Updated code (same as above with the only difference being) and heap dump:
private static Bitmap decodeSampledBitmap(Resource res, int ResId, int width, int height)
{
....
Bitmap bitmap = BitmapFactory.decodeResource(res, resId, options);
return Bitmap.createScaledBitmap(bitmap, options.outWidth/options.inSampleSize, options.outHeight/options.inSampleSize, false);
}
It won't let me post images due to my reputation but according to heap dump it is using 79.155MB. Using the second technique the heap dump is using 26.912 MB.

Are you scaling the Bitmap after decoding it using InSampleSize?

Android - Rotate Image avoiding OutOfMemory

Can the code below cause OutOfMemory ? I think it allows to exceed the application memory limit.
Matrix matrix = new Matrix();
matrix.postRotate(orientation);
image = Bitmap.createBitmap(image, 0, 0, image.getWidth(), image.getHeight(), matrix, true);
What is the best way to rotate an image in Android ?
Allocate it in a service in a new process to get more heap?
#CommonsWare said in this link [1] that many developers think that more heap is a solution for inefficient coding.
This question indicates large heap too [2].
Is there a simpler solution ?
[1] Can you start an IntentService on a separate process?
[2] How to avoid OutOfMemory ex while rotating the image?

The short answer is, Yes, this code may cause OutOfMemory. I don't think that there is a simpler solution than increasing app heap size. I believe that #CommonsWare is right, and often OutOfMemory is an indication of wrong programming. But there are some situations when you need, ehm, huge memory. Rotation of a huge image is definitely one of such situations.
You can use native code (NDK) instead of asking for increased heap size, but this is definitely not easier. And it will still needs lots of memory, so there is no advantage in going for C++ (except that it works on 2.3).

If you wish to use an NDK based solution, I've created one here, and i've made a github project here .
this will avoid OOM by putting the data into the native C "world", recycle the old data, and return the result back, after rotation.
it doesn't require any downsampling.

OutOfMemoryException thrown when your bitmap is to large to load in memory.
Here I am giving you one solution.
BitmapFactory.Options options=new BitmapFactory.Options();
options.inSampleSize = 8;
Bitmap preview_bitmap=BitmapFactory.decodeStream(is,null,options);
Use inSampleSize attribute of BitmapFactory.Options class.
If set to a value > 1, requests the decoder to subsample the original image, returning a smaller image to save memory. The sample size is the number of pixels in either dimension that correspond to a single pixel in the decoded bitmap. For example, inSampleSize == 4 returns an image that is 1/4 the width/height of the original, and 1/16 the number of pixels. Any value <= 1 is treated the same as 1. Note: the decoder uses a final value based on powers of 2, any other value will be rounded down to the nearest power of 2.
//decodes image and scales it to reduce memory consumption
private Bitmap decodeFile(File f){
try {
//Decode image size
BitmapFactory.Options o = new BitmapFactory.Options();
o.inJustDecodeBounds = true;
BitmapFactory.decodeStream(new FileInputStream(f),null,o);
//The new size we want to scale to
final int REQUIRED_SIZE=70;
//Find the correct scale value. It should be the power of 2.
int scale=1;
while(o.outWidth/scale/2>=REQUIRED_SIZE && o.outHeight/scale/2>=REQUIRED_SIZE)
scale*=2;
//Decode with inSampleSize
BitmapFactory.Options o2 = new BitmapFactory.Options();
o2.inSampleSize=scale;
return BitmapFactory.decodeStream(new FileInputStream(f), null, o2);
} catch (FileNotFoundException e) {}
return null;
}

Here:
image = Bitmap.createBitmap(image, 0, 0, image.getWidth(), image.getHeight(), matrix, true);
code operates two bitmaps, the first image is a Bitmap you previosly loaded/decoded into RAM to work with - to rotate actually. And the second one will be created by Bitmap.createBitmap() no matter you store the result into the same variable. Anyway at this line you need bitmap x2 RAM and this causes the OOM for sure (speaking of device's camera biggest possible photos).
I think that using NDK is the best solution here.
Please check my very same question here for additional possible solution (MappedByteBuffer) and it has links to NDK/JNI solutions as well.

Large bitmaps not loading efficiently from sdcard in Android

By following this link, I have written the following code to show a large image bitmap from sdcard.
try {
InputStream lStreamToImage = context.getContentResolver().openInputStream(Uri.parse(imagePath));
BitmapFactory.Options options = new BitmapFactory.Options();
options.inJustDecodeBounds = true;
BitmapFactory.decodeStream(lStreamToImage, null, options);
options.inSampleSize = 8; //Decrease the size of decoded image
options.inPreferredConfig = Bitmap.Config.ARGB_4444;
options.inJustDecodeBounds = false;
bitmap = BitmapFactory.decodeStream(lStreamToImage, null, options);
} catch(Exception e){}
image.setImageBitmap(bitmap);
But it is not returning the bitmap(I mean it returns null). In logcat it is showing the below message repeatedly
08-02 17:21:04.389: D/skia(19359): --- SkImageDecoder::Factory returned null
If I will comment the options.inJustDecodeBounds line and rerun it, it works fine but slowly. The developer guide link I provided above says to use inJustDecodeBounds to load bitmaps efficiently.
Please tell me where I am doing wrong.

inJustDecodeBounds does not load bitmaps. That's the point of it. It loads the dimensions of the bitmap without loading the actual bitmap so you can do any pre-processing or checking on the bitmap before you actually load it. This is helpful is you, say, were having memory issues and you needed to check if loading a bitmap would crash you program.
The reason your bitmap might be loading slowly is because it's probably very large and SD cards are very slow.
EDIT:
From the documentation:
If set to true, the decoder will return null (no bitmap), but the out... fields will still be set, allowing the caller to query the bitmap without having to allocate the memory for its pixels.
Edit 2:
Looking at your code with the example provided by Google, it looks like you are doing relatively the same thing. The reason it's returning null is possibly your InputStream has been modified in the first decoding and thus not starting at the beginning of the bitmap's memory address (they use a resource ID rather than InputStream.
From the code you supplied here, here's what I've figured. You are ALWAYS setting a sample size to 8 regardless of what the first decoding gives you. The reason Google decodes the first time is to figure out what the actual size of the bitmap is versus what they want. They determine that the bitmap is ZxZ dimensions and they want YxY dimensions, so they calculate the samplesize that they should use from the second decoding. You are not doing this. You are simply retrieving the dimensions of the bitmap and not using them. THEN, you set the sample size to a hard-coded 8, swapping it to a hard-coded ARGB_4444 bitmap, then decoding the full bitmap in to memory. In other words, these three lines are not being used:
BitmapFactory.Options options = new BitmapFactory.Options();
options.inJustDecodeBounds = true;
BitmapFactory.decodeStream(lStreamToImage, null, options);
Setting inJustDecodeBounds merely gives you the bitmap's dimensions without putting the bitmap in to memory. It doesn't make it more efficient. It's meant to allow you to load bitmaps in a smaller memory space if they are too big because you can pre-decide what size it should be without decoding the whole thing).
The reason decoding the bitmap is slow might merely be a CPU thing. Depending on the size of your bitmap, you're loading the bitmap from an InputStream from the SDcard which is a slow operation in itself.