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.
Related
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.
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 have a background png in my Android application. I would like to support lots of displays, but I have this one obstacle - many displays have many resolutions and many ratios. I would like to make sure my background is displayed properly and make it more ellegant, than just creating 10+ cropped png files in Photoshop.
My idea would be - a fairly large picture imported in the project. The app would find out screen dimensions and simply say starting points(x,y) and ending points, that would "crop" the picture and display it without any deformations.
Is there a way of doing it?
I think bitmap.createBitmap() is the method your looking after. The method simply lets you cut out a defined portion of the bitmap.
I have two situations/projects where I have to use a large bitmap as background activity.
The first project ports a WP7 application to Android! The WP7 app is using a panorama control with a bitmap as large as 3 screens. I would like to reuse the large bitmap similar in a way that I use the left part for the first activity, the middle part for the second activity and the right part for the third activity. In other words I would like to define which part to crop.
In the second project we try to develop an app which should run on various screen sizes (including tablet), the app should also use a background image. Is it a good idea to provide only one picture with a quadratic size (as long as the largest screen width) and use this picture through every resolution and just crop the background image depending on the actual size of the display?
Is it possible to crop pictures on Android?
Is it possible to define the part of the picture which is kept?
Is it possible to use this croped pictures as background image or may I encounter performance penalties?
What do you think of this technique? Is it a good idea?
Thanks for your help!
answering your questions:
yes it is possible to crop pictures in Android (I've done so)
you can define wich part of the picture is shown in each activity
with a canvas and only drawing the rect that corresponds to the part
of the image that you want to display (eventough I wouldnt suggest
the approach of having diferent activities with the "same" content)
yes, you can use cropped pictures as background image for whatever
you want. Once you cropped the image use that bitmap and save it in
the device and then you might use it as you wish, and eventought is not recommended to have the whole image as background you can do so.
I suggest that you use a SurfaceView since you will be able to move it (the image) all around the screen without having to create a new activity. Here is a good tutorial to SurfaceView Playing with graphics in Android – Part I and this approach will also work with Tablets.
I don't have any problem managing textures. But I didn't work that much with loading textures from images. All I know is that the texture needs to be of size 2^i by 2^i.
But what's the best technique to load any images into a texture. If the images is not a square, I can fit it in the square and add two black parts to fill what is missing. But I'm not sure how to do the stretching.
So, if I have an image of let say 800x600 and I want to put it in a 512x512 square, what's the best trick to copy the pixels into texture ? Or, specially on Android, is there some functions that exists that would do that for me ? In short, it's like I want to resize the 800x600 image to be 512x384 and put it in the texture. But I want to preserve as much information as I can.
The OP Answered his own question with:
SOLVED: a friend showed me some references that covers what I want.
To resize, you can do it with the Bitmap class of Android. You can specify a Matrix, just like the one used for OpenGL to resize the Bitmap. From that point, I expect the pixels to be well preserved and will be able to put them in the texture.
If they come back and put the answer here themselves and accept it then I will delete this answer.