I'm currently writing Bitmaps to a png file and also reading them back to a Bitmap. I'm looking for ways to improve the speed at which writing and reading happens. The images need to be lossless since I'm reading them back to edit them.
The place where I see the worst performance is the actual BitmapFactory.decode(...).
Few questions:
1. Is there a faster solution to read/write from file to a Bitmap using NDK?
2. Is there a better library to decode a Bitmap faster?
3. What is the best way to store and read a Bitmap?
Trying to resolve the best/fastest possible way to read/write image to file came down to using plain old BitmapFactory. I have tried using NDK to do the encoding/decoding but that really didn't make a difference.
Essentially the format to use was lossless PNG since I didn't want to loose any quality after editing an image.
The main concept from all this was that I needed to understand was how long encoding took versus decoding. The encoding numbers where in the upper 300-600ms, depending on image size, and decoding was just fast, around 10-23ms.
After understanding all that I just created a worker thread that I passed images needing encoding and let it do the work without affecting the user experience. The image was kept cached in memory just in case it was needed right away before it was completely encoded and saved to file.
Related
I have found a number of resources but nothing that has quite helped me with what I am looking for. I am trying to understand the .png and.jpg file formats enough to be able to modify and/or read the exif or other meta data in the files or to create my own meta data if possible.
I want to do this in the context of an android application so we can keep if there but it is really not exclusive to that. I am trying to figure out how to do this using a simple imput stream byte array and go from there.
Android itself has to at least extract the RGB pixel information at some point when it creates a bmp image from the stream, I took a look in the BitMapFactory source to try and understand it but I got lost somewhere after delving into the Native files.
I assume the bmps are losing any exif/meta data in the files based on my research. So I guess I want to break the inputstreams down by byte arrays and remove meta data. In .pngs I know there is no 'standard' but based on this page it seems there is some organization of the meta data you can store.
With all that said, I wouldn't mind just leaving exif/png standards behind and trying to store my own information in some sort of standardized way, but I need to know more about how the image readers id the files as either jpg, png, ect. then determine where the pixel information is located.
So I guess my first question is, has anyone done something similar to this before so that they can file me in? If not, does anyone know of any good libraries that might be good for educational purposes into figuring out how to locate and extract this data?
Or even more basically, what is a good way to find meta data and/or the exif standard or even the rgb data programmatically using something like a byte array?
There are a lot of things to address in your question, but first I should clarify that when you say "Android itself has to at least extract the RGB pixel information," what you're referring to is the act of decompression, which is complicated in the case of JPEG, and non trivial even for PNG. I think it would be very useful for you to read through the wikipedias for JPEG and PNG before attempting to go any further (especially sections on header, syntax, file structure, etc).
That being said, you've got the right idea. It shouldn't be too difficult to read in the header of an image as a byte array/stream, make some changes, and replace the old file. A PNG file can be identified by the first 8 bytes, and there should be a similar way to identify a JPEG - I can't remember off the top of my head.
To modify PNG meta data, you'll have to understand "chunks" - types/names, ordering, format, CRC, etc. The libpng website has some good resources for this, here's general PNG info, as well as chunk specifications. Make sure you don't forget to recalculate the CRC if you change anything.
JPEG sections off a file using "markers," which are two bytes long and always start with FF. Exif is just a regular JPEG file with a more specific structure for meta data, and this seems like a reasonable introduction: Exit/TIFF
There are probably libraries for Android/Java that conveniently take care of this for you, but I've never used any myself. A quick google search turns up this, and I'm sure there are many other options if you don't want to take the time to write a parser yourself.
Given a JPEG Encoded byte array taken from a camera, I need to decode it and display its image (bitmap) in my application. From searching around, I've found that there are two primary ways to go about this: use NDK Jpeg Decoding library or use BitmapFactory.decodeByteArray. This is for an experimental embedded device being developed that runs on Android with a built-in camera.
I would greatly prefer to develop the application in SDK not NDK if possible at all, but many people seemed to handle this problem by going straight to NDK, which bugged me a bit.
Is there some sort of inherent limitation in BitmapFactory.decodeByteArray that forces you to handle this problem by using libjpeg in NDK (Perhaps speed? Incompatibility?)
Performance isn't a big consideration unless if it takes say more than 45 seconds to decode the image and display it.
This is an important decision I need to make upfront, so I'd appreciate any thoughtful answers. Thank you so much.
Here is a really good example / explanation how you can decode images on device efficiently without using NDK : Displaying Bitmap Efficiently. You have an option to decode bitmap from stream or file so it depends on your needs. But in most of my applications I am using the same method and it's working great. So I suggest you to take a look at the SDK example.
Hope it will helps you.
I need to get the pixels info from a Jpeg image without instanciating a Bitmap and then pass it to the JNI.
It is impossible with android to get anything else than a jpeg image from camera (except if you need a low resolution in which case you can use thePreviewCallback), so I got the byte[] from the jpegCallback.
Is it possible to get pixels info in an int[] without using Bitmap.getPixels() ?
If you don't want to construct a Bitmap, your only option is to decode the JPEG buffer yourself; this means either finding another Java JPEG decompression library, or using JNI and a C JPEG library such as libjpeg. Or, you can write one from scratch, which I don't recommend unless you're already pretty conversant with image compression routines, and you have plenty of time for implementation and debugging.
As Scott asked, why is using Bitmap unacceptable? No matter what route you take, you'll have to call something to decompress the image data, and using BitmapFactory.decodeByteArray is a straightforward, known-to-work option.
I do not see how this is possible with the standard Android APIs. I'm sure there are 3rd party JPEG libraries you could use (Googling finds may possibilities). Why are you trying to avoid Bitmaps? If it is a memory constraint, you might want to decode small horizontal chunks with BitmapRegionDecoder
We are working on an native Android app that handles large images (5MP+) from the phone's gallery, eventually encoded base 64, JSONized and sent to an upstream server. We've used some of the guidance given in other StackOverflow questions. We've tried hard to keep memory usage to a minimum, following logcat closely, debugging, etc. And while we've gotten under control the "80% use case" we still are getting FATAL errors in certain cases (when the user picks a photo, then cancels, chooses a different one, for instance).
We've found that when importing a 5MP Bitmap, its size quadruples in the Heap (i.e. a 7Mb jpeg becomes 28Mb in memory). We've used tricks to convert to Base64 as efficiently as possible. We've made sure the JSON parser is not leaking and so forth.
So to get back to my original question, is there a way to circumvent Android's Bitmap handling?
eventually encoded base 64, JSONized and sent to an upstream server
Rewrite your Web app to support binary payloads, so that you do not have to do ridiculous stuff like this. Upload JSON-encoded metadata in one request, then upload the image in its original format in a separate request, if need be. Or, use multipart upload to do both in one shot, leaving the image in its original format.
We've found that when importing a 5MP Bitmap, its size quadruples in the Heap (i.e. a 7Mb jpeg becomes 28Mb in memory)
That is because PNGs, JPEGs, and the like are compressed, and the image needs to be uncompressed to be displayed.
is there a way to circumvent Android's Bitmap handling?
You do not say if you are trying to display the image or not. If you are, use BitmapFactory with an appropriate BitmapFactory.Options to scale the image.
If you are not trying to display the image, once you rewrite the Web app to accept a binary payload, you should not need to load the entire image into memory. Just upload it in the format that it already is in, reading in chunks at a time (e.g., 8KB) to write to the OutputStrem of your HTTP PUT (or whatever) for the upload.
I'm looking for a way of obfuscating the images I store in my application and am currently considering Base46 Encoding.
I need something with minimal overhead or if possible a performance boost over standard files on the file system.
Can someone comment on the feasability of base64 encoding the images (png) and subsequently using (decoding?) on the target platforms?
Thanks.
What sort of attack are you trying to protect against? Base64 is reasonably easily recognizable and has a potentially-significant impact in terms of space (each image will take an extra 33% space).
Some sort of shifting XOR would be harder to spot just from the data, but it wouldn't be adequate protection for really significant assets.
I am sure you understand Base64 won't fool anyone who really want to get your Bitmap.
Jon Skeet is right, Base64 is nice to encode binary data in readable format but will not really help you here. An XOR against a password of yours will be faster, and won't add any size overhead.
If you really want to obfuscate your bitmaps I suggest you to store them in the "raw" ressources folder. By doing this you will be able to keep the nice Android abstraction that handles different form factors (ldpi, hdpi, ...).
Extends the ImageView class to directly work with R.raw.filename id and do the reading file/decoding stream/creating bitmap there. By doing so, you will be able to rollback easily to the standard way of doing things if needed.
Be warned that you could run into memory issues when storing multiple bitmaps within an application memory in Android. OutOfMemoryErrors seem to be a recurring problem when dealing with bitmaps in android. Here is an example: outofmemoryerror-bitmap-size-exceeds-vm-budget-android