I'm having memory problems and think it might have to do with creating large bitmaps.
The task at hand is to get a fairly small tile image and create a larger tiled image and set this as the phone wallpaper. The way I'm doing this is:
1) Create a view that is 2 * screen width, 1 * screen height
2) Set the view background to a BitmapDrawable with the tile mode set to repeat
3) Create a bitmap with the views dimensions
4) draw the view to the bitmap by: view.draw(new Canvas(bitmap))
5) set wallpper: getApplicationContext().setWallpaper(bitmap)
This works fine on my phone (HTC Magic) and other phones that I have tried. But I am getting bug reports relating to this issue. I tried to recreate the problem by doubling the required dimensions and the problem seems to be happening in the 4th step when the view is being drawn to the bitmap:
ERROR/dalvikvm-heap(124): Heap Massage needed (7372800-byte external allocation too big)
I'm not sure how to go about solving this. Please help!
Thanks
I'm sure you thought of it, but nevertheless: Have you included
<uses-permission android:name="android.permission.SET_WALLPAPER" />
in your manifest-file?
You're sure there is no exception thrown? It could possibly be a problem with showing the Toast.
Not exactly sure if this is your solution, but have you looked at ? BitmapFactory.Options.inTempStorage
The way you use it is:
BitmapFactory.Options options = new BitmapFactory.Options();
options.inTempStorage = new byte[16*1024];
Bitmap bitmap_origin = BitmapFactory.decodeFile(path, options);
Unfortunately, I don't think you can do much... We are on a mobile phone here ; Android limis the process memory to 16MB.
Here are a couple of tips and tricks I can give you (because I have the sames issues in my application)
Are you sure you need 32 bits pixels? that's three 8bit color channels plus a 8bit alpha channel. You can use RGB_565 for a visually acceptable result.
Recycle the image that you don't need when you create your bitmap (and that you won't need to draw your bitmap)
null any other object that you don't need
Run System.gc() to force a garbage collection just before you create the Bitmap
Hope this helps!
Actually you could refactor your code. You'll have better performance and probably use less memory if you don't use a View
Create a Bitmap of the desired size bitmap = Bitmap.createBitmap(width,height,Bitamp.Config.RGV_565) (or ARGB_8888, that might work too)
Create a canvas = new Canvas(bitmap)
Create the tiled image yourself, from your src
simplified Code:
// set another matrix if you want rotation/scaling of the input
Matrix identity=new Matrix();
for (int i=0; i<maxLines; i++) {
for (int j=0; j<maxCol; j++) {
canvas.draw(src, identity,anyPaint);
}
}
Keep the end set wallpaper getApplicationContext().setWallpaper(bitmap)
Related
I want to crop image without getting OutOfMemory exception.
it means i have x, y, width and height of cropped image and want to crop original image without bringing it to memory.
Yes i know that BitmapRegionDecoder is good idea but maybe the cropped image would be too large for bringing it to memory.
In fact i don't want copped bitmap, just want to write cropped image from source file to destination file.
EDIT : I want to save cropped image not just showing it in an ImageView
I want to save it in a new file without losing dimensions
This is the example
in this situation cropped image resolution is 20000x20000 and code below wont work cause of OOM:
BitmapRegionDecoder bitmapRegionDecoder = BitmapRegionDecoder.newInstance(inputStream, false);
BitmapFactory.Options options = new BitmapFactory.Options();
options.inPreferredConfig = Bitmap.Config.RGB_565;
Bitmap bitmap = bitmapRegionDecoder.decodeRegion(new Rect(width / 2 - 100, height / 2 - 100, width / 2 + 100, height / 2 + 100), options);
mImageView.setImageBitmap(bitmap);
using inSampleSize to decrease the original picture size is good but the result i save is no longer 20000x20000.
How can i crop the 25000x25000 and save the 20000x20000 part of image in a file?
Simply put, it requires lots of low level programming and optimizations.
as you can see, lots of answers in this region are pointing to generic concepts of bitmap compression, etc which are indeed applicable in most issues but not specifically yours.
Also BitmapRegionDecoder as suggested in answers won’t work well. It sure prevents loading the whole bitmap in RAM but what about the cropped image? after cropping an image it gives you a giant bitmap which no matter what, gives you an OOM.
Because your problem as you described, needs Bitmaps to get written or get read from disk just as they get written or read from memory; something called a BufferedBitmap (or so) which efficiently handles the memory it requires by saving little chunks of a bitmap to disk and using them later, thus, avoiding OOM.
Any other solution which wants to tackle the problem with scaling only do half of the work. why? because cropped image itself can be too big for memory (as you said).
However, solving the problem by scaling isn’t that bad, if you don’t care about the quality of the cropped image compared to the quality user had seen when she was cropping it. that’s what the Google Photos do, it simply reduces the quality of cropped image, very simple!
I haven’t seen any BufferedBitmap classes around (but if there are, it would be awesome). They sure become handy for solving similar problems.
You can check Telegram messaging app which comes with an open-source implementation of image cropping facilities; you guess right, it handles all the similar nasty works with good old C... Hence, we might conclude that a good global solution (or better said, ONE OF THE SEVERAL APPLICABLE SOLUTIONS) appears to be low-level programming to handle disk and memory yourself.
I know my answer failed to give any copy-paste-ish solution to your problem but at least I hope it gave you some ideas my friend.
Did you checked BitmapRegionDecoder? It will extract a rectangle out of the original image.
BitmapRegionDecoder bitmapRegionDecoder = BitmapRegionDecoder.newInstance(inputStream, false);
BitmapFactory.Options options = new BitmapFactory.Options();
options.inPreferredConfig = Bitmap.Config.RGB_565;
Bitmap bitmap = bitmapRegionDecoder.decodeRegion(new Rect(width / 2 - 100, height / 2 - 100, width / 2 + 100, height / 2 + 100), options);
mImageView.setImageBitmap(bitmap);
http://developer.android.com/reference/android/graphics/BitmapRegionDecoder.html
You can solve this using BitmapFactory. To determinate the original bitmap size without putting it in to memory, do the fallowing:
BitmapFactory.Options options = new BitmapFactory.Options();
options.inJustDecodeBounds = true;
BitmapFactory.decodeResource(..., options);
int originalImageWith = options.outWidth;
int originalImageHeight = options.outHeight;
Now you can use options.inSampleSize
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.
Now it's not a perfect solution but you can do math to find what is the closest factor of 2 that you can use on options.inSampleSize to save memory.
BitmapFactory.Options options = new BitmapFactory.Options();
options.inSampleSize = sampleSize;
Bitmap bitmap = BitmapFactory.decodeResource(..., options);
BitmapRegionDecoder is the good way to crop big or large Images, but it's available from API 10 and above.
There is a class called BitmapRegionDecoder which might help you, but it's available from API 10 and above.
If you can't use it :
Many image formats are compressed and therefore require some sort of loading into memory.
You will need to read about the best image format that fits your needs, and then read it by yourself, using only the memory that you need.
a little easier task would be to do it all in JNI, so that even though you will use a lot of memory, at least your app won't get into OOM so soon since it won't be constrained to the max heap size that is imposed on normal apps.
Of course, since android is open source, you can try to use the BitmapRegionDecoder and use it for any device.
Reference :
Crop image without loading into memory
Or you can find some other way on below that might be helpful to you:
Bitmap/Canvas use and the NDK
I want to use coverflow view in my app. To get the reflection image part i have used the following code - http://www.androidsnippets.com/create-image-with-reflection
I have seen lot of forums/discussions about dithering and tileMode, I have tried all that discussed but nothing works for me.
FYI - I am creating a bitmap dynamically not using any bitmap in layouts. And I have attached the image to show how bad it is:
I have listed below what I have tried to solve this issue.
1. getWindow().setFlags(WindowManager.LayoutParams.FLAG_DITHER, WindowManager.LayoutParams.FLAG_DITHER);
2. getWindow().setFormat(PixelFormat.RGBA_8888);
3. BitmapDrawable baseImageDawable = new BitmapDrawable(getResources().openRawResource(imageId));
baseImageDawable.setDither(true);
baseImageDawable.setTileModeXY(Shader.TileMode.REPEAT, Shader.TileMode.REPEAT);
Bitmap originalImage = baseImageDawable.getBitmap();
int width = originalImage.getWidth();
int height = originalImage.getHeight();
Bitmap reflectionImage = Bitmap.createBitmap(originalImage, 0, 0, width, height, matrix, true);
But still the reflection image is very ugly.
How can I solve this?
Hmmm. I "think" your problem is that your bitmap is not being created as ARGB_8888 (despite your setFormat call). I would "suggest," instead of creating the Bitmap drawable using openRawResource, use BitmapFactory and make sure you specify Bitmap.Config.ARGB_8888. Then make your drawable from the bitmap. Just a thought--hard to guess at this distance without being able to step with eclipse. You might find this article interesting: http://www.curious-creature.org/2010/12/08/bitmap-quality-banding-and-dithering/
Edit: So, the problem, apparently, was in the call to createBitmap being used to allocate the reflectionImage. Moral of the story (IMHO): never use createBitmap methods that do not allow you to explicitly specify Bitmap.Config. Otherwise, as Forrest Gump might say, you never know what you're gonna get.
I found the location where should I set the config. While creating the reflection bitmap set the config as ARGB_8888. Its working now.
I'm sorry if this topic has been brought before, but all my searches on the web and google groups did not help me.
I'm currently developing a little game with the Android SDK, and use hi-res bitmaps that I resize accordingly to match the device's resolution (letting the system do it for me is
not "crisp" enough).
I use a SurfaceView, on which I paint in one pass a canvas filling the whole surface. The paint uses setXfermode(new PorterDuffXfermode(PorterDuff.Mode.SRC_IN)) to allow masking.
Beforehand, I retrieve various bitmaps -- which are resized at initialization with createScaledBitmap() and put in a cache -- and I apply the bitmaps with a paint on this canvas, before drawing this canvas on the SurfaceView.
My problem is, whatever I try, whatever paint settings I use (dithering, antialias, etc..), the resized bitmaps are not antialiased and the drawing present jagged edges. I tried everything.
The only little success I had was using inSampleSize to approach the desired scaled size and force a first pass of antialiasing, before invoking createScaledBitmap on the retrieved
hi-res bitmap, but it is not beautiful enough. I just can't allow to create multitudes of pre-sized bitmaps for every combination of resolution. What did I miss ?
Thanks a lot in advance
First when you load your bitmap you make sure that you don't lose any image quality by settings options to argb_8888:
Options options = new Options();
options.inScaled = false;
options.inPreferredConfig = Bitmap.Config.ARGB_8888;
Bitmap pic = BitmapFactory.decodeResource(getResources(), R.id.pic, options);
When you scale the bitmap turn on the filter:
pic = Bitmap.createScaledBitmap(pic, screenW, screenH, true);
However if one streaches the image too much inevitably it degrades in quality.
When you use paint you can improve quality but lose on speed with turning on ditherig and filtering:
Paint paint = new Paint();
paint.setFlags(Paint.DITHER_FLAG);
paint.setFilterBitmap(true);
Finally the entire activity window could be set on argb_4444 instead on argb_8888 (OS < 2.3). You can chage this if you instert this line before setContentView:
getWindow().setFormat(PixelFormat.RGBA_8888);
If it comes down to it, you can manually antialias without too much trouble. Just apply a simple lowpass filter (something like an NxN average) to the pixel data before asking the bitmap object to rescale itself.
you may clear canvas buffer by youself! such as follows:
canvas.drawColor(Color.TRANSPARENT, android.graphics.PorterDuff.Mode.CLEAR);
I am trying to composite a background bitmap from multiple smaller bitmaps. I am using Eclipse with the Android SDK.
I have loaded a (mostly) blank background bitmap (pixel dimensions are 320x480) like so:
Bitmap mBackground = BitmapFactory.decodeResource( res, R.drawable.background );
Then I load a bitmap 'tile' (128x128) the same way.
I have tried multiple ways of drawing the tile onto the bitmap but every single method does not work the way I would like/expect. I want to draw the tile bitmap scaled down to 64x64 and at a specific location (pixel offset) on the background bitmap.
1) Using a Canvas...
Canvas c = new Canvas( mBackground );
c.drawBitmap( mTile, null, new Rect( 10, 10, 73, 73 ), null );
This draws the tile way too big (not fullsize, not 64x64, but somewhere in between, about 66% of original)
2) Using drawables (which basically seems to be the same):
Canvas c = new Canvas( mBackground );
c.translate( 10, 10 );
d.setBounds( 0, 0, 63, 63 );
d.draw( c );
Same result as experiment #1...
The documentation mentions in numerous places (without a concise explanation anywhere) that this has to do with the device independent 'densities' thus I tried the next approach...
3) Using fixed scale resources. I created the /res/drawable-nodpi (I also tried just /res/drawable) folder and moved my resources (background and tile png images) into it. That causes an exception when creating the Canvas from the background Bitmap because an unscaled bitmap apparently becomes immutable and therefore cannot be assigned to a Canvas!
4) I tried using BitmapFactory.Options and setting inScaled to false, and passing those options to both of the decodeResource calls for the background and the tile. This has the exact same effect as #3 (exception thrown).
Nothing has worked and its becoming quite frustrating. I am sure I am just missing some detail that is peculiar to bitmaps when it comes to the different coordinate spaces but I cannot find it anywhere in the documentation or elsewhere (I've tried multiple android development sites to no avail).
Hopefully someone who has done this will see this plea!
Thanks, jason
Canvas.drawBitmap() does not perform scaling afaik.
Since your tile image is originally 128x128 and you want to draw it at 64x64, the simplest trick would be to call decodeResource() with the option to reduce it in size:
BitmapFactory.Options options = new BitmapFactory.Options()
options.inSampleSize = 2; // downscale by 50%
Bitmap mTile = BitmapFactory.decodeResource( res, R.drawable.tile, options );
To do more powerful scaling (e.g. drawing your image at any size) you should wrap it in a BitmapDrawable.
It looks like the densities of your bitmaps are different... There is a similar issue here. You should check the density of each Bitmap you load to see if it's the same problem.
Say I have a somewhat large (i.e. not fit in most phones' memory) bitmap on disk. I want to draw only parts of it on the screen in a way that isn't scaled (i.e. inSampleSize == 1)
Is there a way to load/draw just the part I want given a Rect specifying the area without loading the entire bitmap content?
I'm quite confident this is possible since you can load a really large bitmap file into an ImageView without problems so there must be some sort of a built-in way to handle large bitmaps... and after a few attempts, I've found a solution:
Instead of loading the entire bitmap and manually draw it yourself, load it as a Drawable instead:
InputStream mapInput = getResources().openRawResource(
R.drawable.transit_map);
_map = Drawable.createFromStream(mapInput, "transit_map");
_map.setBounds(0, 0, _mapDimension.width(), _mapDimension.height());
I'm using a resource file but since you can use Drawable.createFromStream to load image from any InputStream, it should works with arbitrary bitmap.
Then, use the Drawable.draw method to draw it onto the desired canvas like so:
int left = -(int) contentOffset.x;
int top = -(int) contentOffset.y;
int right = (int) (zoom * _mapDimension.width() - contentOffset.x);
int bottom = (int) (zoom * _mapDimension.height() - contentOffset.y);
_map.setBounds(left, top, right, bottom);
_map.draw(canvas);
As in the above case, You can also scale and translate the bitmap as well by manipulating the drawable's bounds and only the relevant parts of the bitmap will be loaded and drawn onto the Canvas.
The result is a pinch-zoomable view from just one single 200KB bitmap file. I've also tested this with a 22MB PNG file and it still works without any OutOfMemoryError including when screen orientation changes.
Now it's very relevant: BitmapRegionDecoder.
Note: available since Android SDK 10
It can easily be done by using RapidDecoder.
import rapid.decoder.BitmapDecoder;
Rect bounds = new Rect(10, 20, 30, 40);
Bitmap bitmap = BitmapDecoder.from("your-file.png")
.region(bounds)
.decode();
imageView.setImageBitmap(bitmap);
It supports down to Android 2.2 (API Level 8).
Generally speaking, that isn't possible, particularly since most image formats are compressed, so you don't even know which bytes to read until you've extracted the uncompressed form.
Break your image up into small tiles and load just the tiles you need to cover the region you want to display at runtime. To avoid jittery scrolling, you might also want to preload tiles that are just out of sight (the ones that border the visible tiles) on a background thread.