I've been having problems with large images being resized for UI use in Android.
Look at this image, it's an ImageView:
The original image (That arc is a progressbar) is around 10 times bigger than what you see here. In UWP (Windows Platform) we had no problem using a very large image, but here in Android, I beleive it's the Nearest Neighbour method used for fitting images into UI elements, which as you see, causes sharp edges.
Is there any way to switch it into another method? Like Bicubic? It happens in all Android versions I've tested (4.1, 5.0, 6.0).
Just to mention, I'm using Xamarin 4, which I don't beleive as a contributing factor here.
No luck searching through the internet, I'm afraid I'm the only one having this problem.
Thanks.
As mentioned above, you should prefer to use vector image instead of pixel image.
But if you have to use pixel image, maybe you could use BitmapRegionDecoder to decode lines of image and write your own resample algorithm(like Bilinear Interpolation, it's much better than the Near Neighbor) to resize the image, typically in JNI side.
Another possible way is to use "filter" parameter while calling Bitmap.createBitmap method as your original image would not cause OOM issue, just set it to true, it works to reduce the artifacts.
You should use Vector Images instead of Bitmap Images.
Bitmap x Vector
A bitmap represents an image by a series of colored pixels. Whereas a vector image is represented by geometric shapes (lines, curves) using colors.
The main utility of a vector image is allowing to scale without losing definition.
Related
Android Lollipop has introduced several new classes, one of them being VectorDrawable. I was just wondering when will it be suitable to use VectorDrawable over a bitmap image knowing VectorDrawable has a performance drawback. The only thing with VectorDrawable is scalability which comes at the cost of performance. So when is it that I can use a VectorDrawable if performance is the priority? Is the performance drop too high?
I think the "performance drop", if present, would be acceptable. One would hope you are not creating a ton of vector drawables every frame. Presumably, you would load the VD once, cast it into a drawable at which point the vector drawable isn't needed anymore.
Really the only thing that I can see that would cause an issue, is if you are loading an absurd amount of them all at once. But why would you? At that point, just something like a presized sprite sheet.
Note that VectorDrawable (comparing with BitmapDrawable), only has the initial drawing performance overhead. After the 1st frame the VectorDrawable show up, the framework will have a bitmap cache. From that on, all the performance of that VectorDrawable should be the same as the BitmapDrawable, as long as the size didn't change.
VectorDrawable is not recommended for huge background image, like full screen size, but for buttons and icons whose size is normally smaller than something like 200dp x 200dp. You should be able to use it without worrying too much about the performance.
I'm currently able to blur a whole bitmap (by resizing it down than up for example).
The effect I'm trying to accomplish is a selective blur : the result bitmap would be blurred, minus a round / oval part of it which would still be sharp :
The difficult part is that the sharp oval part could be smaller or bigger, and should be movable (its coordinates aren't always the center of the original bitmap).
I already found a solution, but I don't think of it as a good performance wise solution :
Copy the original bitmap into two different bitmaps (background and foreground)
Blur the background one
Crop the foreground one into the desired shape (round or oval)
Erase the borders of the foreground a bit (to avoid a too sharp difference between foreground and background images)
Put back the two images together
Export it as a bitmap
One another solution could be to recreate a blur algorithm which would run through every pixel of the original bitmap and apply an amount of blur higher or lower depending on the portion of the bitmap.
I finally decided to follow my first idea, using #DerGolem links. Here is the updated version of the chart :
The algorithm is quite simple:
We create two copies of the bitmap : the first one will serve as the background, while the other one will be used as the sharp part of the picture. To avoid the second one to be too sharp, we'll use a prepared mask (stored in the drawables folder)
We blur the first one as much as we want
We apply the mask to the second bitmap
We create a bitmap from those two previous steps
I created a sample demo application, hosted on BitBucket. You can clone the project and try it, the performances are much better than what I expected!
In order to achieve this, I used the following resources:
RenderScript to blur the background, much better than resizing the image down and up : 1, 2
Understand Porter/Duff
As said in the project's readme, the provided code is far from being perfect, but it works.
I'm having trouble cleanly down-scaling images on Android. I'm looking to scale small PNG images between arbitrary sizes of about 10-100% of their original size.
I've created a sample image to demonstrate the problem and exacerbate the unusual behaviors I'm seeing in Android's image scaler:
The above image is a screenshot from an Android device with some annotations added. I've also added the same images in a second column on the left side showing how they are rendered with a linear scaling by "The GIMP" (GNU Image Manipulation Program).
The base image consists of a checkerboard pattern background of red and blue pixels. On that background I've drawn some 1px-wide yellow lines and fairly thin green text. The image is 288x288 pixels.
When scaling the image to 1/3 of its original dimensions, Android seems to simply grab one in nine pixels, throwing out all other data. Some of the yellow lines disappear entirely as a result. Remarkably, the checkerboard pattern remains intact (which is simply a result of every 3rd pixel being used).
When scaling the image to a dimension of near-but-not-exactly 50% of its original size, e.g., 142x142 or 143x143, the scaler creates some fairly large anomalies/artifacts on the image.
At 50% size (144x144), the image looks correct.
The test image does bring out the worst of the image scaler, but "normal" PNG icon images are severely impacted as well. From 10-33% or so the images aren't properly resampled, and thus appear extremely "bitmapped". And certain larger size images have very strange anomalies in them at certain sizes.
If anyone knows a means to disable this strange scaling behavior, even at a performance cost, I'd greatly appreciate knowing about it. It can certainly be solved by writing an algorithm that works directly on the pixels of bitmaps, but I'm hopeful that isn't the only option.
Also noteworthy is the fact that all image work is being done with ARGB_8888 Bitmap.Configs. I've tried manipulating image size by setting maxwidth/maxheight on ImageViews, by using Bitmap.createScaledBitmap(), and by using Bitmap.createBitmap with a Matrix. All attempts have this same result. Bitmap filtering is enabled.
Thanks again for any suggestions!
Using Bitmap.createScaledBitmap() and Bitmap.createBitmap with a Matrix is the same; see the source for Bitmap.createScaledBitmap (which hasn't changed since Android 2).
On Android 4.0+, using a matrix (as in Bitmap.createScaledBitmap) allows hardware-accelerated operations if enabled (enabled by default on 4.1+ IIRC), thus we doesn't have direct control over what is being done and how it is done.
That means you'll have to implement your own scaling method using the desired (here, linear) filtering; either by pixel processing; or using OpenGL ES with the good filter, but it may not be available on all devices.
i was wondering if is it efficient and possible to set 3000X2000px image as canvas background without resizing it and without getting the memory error.
because i want the real size image and pan around it.
using webview is not an option.
Currenty i tried to the set the background by using a folder structure named "Drawable-nodpi" and then assinging the bitmap image with decoderesource method.
Such a huge picture will inevitably cause outofmem exceptions on at least some devices. So I think that you need to dynamically scale and load only parts of the image that needs to be displayed, possibly with a caching mechanism.
Unfortunately, I don't know about any library components for Android that does this for you out of the box, but I'm pretty sure that you can find some nice articles on this topic.
I am fighting against OutOfMemoryError in my app.
I created a background image, which is 800 pixel x 480 pixel. When this image is loaded into the view that uses it as background, I think the OS will use 800*480*4 bytes for it. It is a lot of memory.
If I create a 10 pixel x 10 pixel 9-patch image to replace the whole screen image. The OS will auto-scale the 9-patch image to 800x480 when it renders the view that uses the 9-patch. My question is that, in the 9-patch case, how much memory will OS use to draw the scaled 9-patch image? will it be 10*10*4 bytes or 800*480*4 bytes?
Thanks.
Firstly, if it is a background image, and could be scaled, please do so, as it is known to be the best practice (especially for backgrounds) and the slight loss of image clarity could be compensated by choosing the correct colours and/or background pattern.
Regarding memory, if you are using Drawable you are on the safe side. But the Bitmaps are apparently not allocated in a standard Java way but via native calls; the allocations are done outside of the virtual heap, but are counted against it. More on this problem here