I have an image processing app, and I have to remember which photos have already been processed. In order to do so, I store an EXIF metadata in the image file, but if the user decides to send the image over WhatsApp, etc, the metadata is lost, so I can't rely on this.
So I though a solution would be to use some pixels in the image to remember if the photo was processed or not, something like if that pixel has that color and that other that other color, then it was processed.
I have tried to do so, but if the image gets scaled down, then my approach won't work.
Any ideas on how to do it?
Thank you.
This is a quite complicated topic and there's no silver bullet that'll help you. One pitfall is the fact that most image compression algorithms try to throw away data our eyes cannot see, and your watermarking algorithm would then have to make modifications that are visible to the human eye, which is probably not what you want.
Another thing to note is whatever you do, if you go with the route of storing data using pixels, you're going to have false positives.
What you could do, since your app already does image processing, is to embed your application's logo as a watermark into the image somewhere. Then you can attempt to find distinct features of your logo in the image, which is admittedly not very easy, but neither is the problem.
Again, this problem is already quite complicated so I'm sorry if this answer isn't adequate.
Related
I am new to Android Studio. While working on front end its sometimes easy to take some parts as png file and place it on the particular position instead of recreating it in xml file. I am confused can we use png all the time ? I am worried about memory space . Like the app contains 50 pages and in each page I use 1-2 assets . I don't want my app to have more than 40mb. What will be the best way to do? Can we store the image as a URL and retrieve it whenever we use. What's the drawback in that way?
So many questions :)
I am confused can we use png all the time ?
Use what's best for your picture. For a photo, a JPEG will probably do better. But if you wish, you can use PNG all the time, yes.
I don't want my app to have more than 40mb.
Check and see. Depends on how big your images are; we can't tell.
What will be the best way to do?
Not enough information to tell you that. In general, there's nothing wrong with using images in assets.
Can we store the image as a URL and retrieve it whenever we use.
Yes.
What's the drawback in that way?
You'll need to get some server space somewhere. Also, there will be a loading latency. Also, your app won't be usable while disconnected from the Internet.
While working on front end its sometimes easy to take some parts as png file and place it on the particular position instead of recreating it in xml file.
That's the part that is confusing to me. Android XML layouts usually contain interactive elements, ones that the user can interact with. Images, on the other hand, tend to be static. What kind of XML is there out there that you think you can replace by an image?
In what language(s) is it (if at all possible) to check the content of an image?
Ideally, I am looking for web / mobile languages, but whatever is possible.
As a comparative example, I wish to make the first image of a castle 'valid' and the second image of the wall 'invalid', due to there been no substantial content in the second image. Meaning, the second image, which is the wall, has too much similarity across the image and therefore doesn't contain valid content.
Please do not provide a 'how to do it', as I am a student and will be working out solutions for myself as much as possible, I just need to know that what I want to achieve is possible in the first place and a starting point for language(s).
**EDIT2: What Javier has suggested about computer vision is on the right track to what I mean. Image analysis to break it down a little more. I wish to visually analyse an image and determine how the range of varied the colours across an image are to determine if there is actually a proper image present on not just a picture of a wall
Ive been using various lazy loading techniques for images and other things. It works but I was wondering if there is a better way that some one knows of for getting an image from a server/webservice/whatever that doesnt require as much memory or time to download. The reason I ask is because I have an overseas developer asking me to rebuild a webservice for a project and hes asking me to allow them to just use a url to get the image. My thought was that whether its a url or a post to a service the result still has to come back via an inputstream which is going to take up the same memory whether virtual or stored in hard storage. His question had me slightly confused so out of curiosity Im asking on here......is there a way to get an image without using an inputstream? I guess it would be like a calorie free image lol.
You can blit the big image into a small image and discard the big one. This is how thumbnails work in image programs.
I have to believe there's a way to clear image data from memory once it's no longer required, but despite exhaustive searching I can't find a solution. Both stack and the google android dev list are full of questions regarding OOM errors, specifically "bitmap size exceeds VM budget", but I still don't see a clear answer.
I understand there are hard memory limits on devices, and I understand it's not realistic to load up and display or cache large amounts of image data, but there should be away to discard data that's no longer required.
For example, imagine this very basic hypothetical app, that emulates a lot of the behavior of the native gallery app:
An image gallery that allows the user to peruse images from a remote server.
There might be any number of images on that server.
The app displays 1 image at a time, and allows a user to go back or forward 1 image at a time through button presses or swiping.
There'd be a maximum of 3 images rendered at any one time (so the user can see the one immediately to the left or right of the current image when swiping). All other image data should be discarded.
Images are loaded using URL.openStream and Drawable.createFromStream or BitmapFactory.decodeStream. Streams are closed appropriately.
Images are sized appropriately on the server before being fetched.
Loading happens in AsyncTasks. Tasks that are no longer needed (due to moving away from an image with an incomplete task) are cancelled. Any references in the AyncTask are WeaklyReferenced.
When any image is no longer required, it's "cleared" via:
getBackground().setCallback(null)
Listeners are set to null
setImageDrawable/Bitmap(null)
removeView
This simple construct, that takes into account all the suggest practices I'm aware of, will inevitably crash with an OOM error at some point. Using BitmapFactory.Options inSampleSize and inPreferredConfig will delay the inevitable, but not forever, and at the cost of image quality. In this example, I've used remote images, but the issue exists with images stored in /assets/ or in internal memory, etc.
My feeling is that if we can display X amount of image data at one point, and we take all steps to remove that image data from memory, we should be able to display that same amount of data later, without having to compensate for what has happened before.
With the sheer quantity of questions about this very issue, I'd hope to have a standard solution documented, but if there is one, I can't find it. I've seen answers posted by Romain Guy, who otherwise seems very generous with his knowledge and active in the community, that say something like "Simple. Don't use so much memory". OK. Tell me how.
I should also mention that System.gc does nothing to help this. I'm also aware of bitmap.recycle, but unless I'm mistaken this can't be used in this fashion.
Am I missing something fundamental? Is there a way to discard image data once it's no longer being used? What is missing from the above to create a simple photo gallery? Assuming the built-in gallery app uses the framework and not the NDK, I imagine there has to be a way...
TYIA.
/this question has also been posted on the android developer google group list.
Through my work with Prime I found a few tips, one of which you have not mentioned. When you decode your Bitmaps make sure to use the inPurgeable and inInputShareable flags in your BitmapFactory.Options. That will help a little bit but I would recommend you look at my implementation of image loading in Prime. I use it in all of my products without any memory issues. I have found that 95% of memory problems are from the incorrect usage of the Bitmap class.
There is a very detailed article about the use of bitmaps on the android developer website.
Did you look at it ?
It explains how to load, cache and display bitmaps efficently and how to get rid of this famous OutofMemoryError.
There is also a sample application from an image gallery.
I think that's what you're looking for.
Application size on a phone needs to be as small as possible. If I have an image of a sword and then a very similar image of that same sword except that I've changed the color or added flames or changed the picture of the jewel or whatever, how do store things as efficiently as possible?
One possibility is to store the differences graphically. I'd store just the image differences and then combine the two images at runtime. I've already asked a question on the graphic design stackexchange site about how to do that.
Another possibility would be that there is that apk already does this or that there is already a file format or method people use to store similar images in android.
Any suggestions? Are there tools that I could use to take two pngs and generate a difference file or a file format for storing similar images or something?
I'd solve this problem at a higher level. For example, do the color change at run-time (maybe store the image with a very specific color like some ugly shade of green that you know is the color to be fixed at run-time with white or red or blue or whatever actual color you want). Then you could generate several image buffers at load-time.
For compositing the two images, just store the 'jewel' image separately, and draw it over the basic sword. Again, you could create a new image at load-time, or just do the overdraw at run-time.
This will help reduce your application's footprint on flash, but will not reduce the memory footprint when the app is active.
I believe your idea of storing the delta between 2 images to be quite good.
You would then compress the resulting delta file with a simple entropy coder, such as Huffman, and you are pretty likely to achieve a strong compression ratio if similarities with base image are important.
If the similarity are really very strong, you could even try a Range Coder, to achieve less-than-one-bit-per-pixel performance. The difference however might be noticeable only for larger images (i.e higher definition than a 12x12 sprite).
These ideas however will require you or someone to write for you such function's code. This should be quite straightforward.
An very easy approach to do this is to use an ImagePack ( one image containing many ) - so you can easy leverage the PNG or JPG compression algorithms for your purpose. You then split the images before drawing.