Dealing with ARGB_8888 full-sized images may just not be possible for certain devices (e.g. 5MPixel images taking 20Mbyte of memory, not leaving much room for anything else). Unless you can decode the byte[] data from the Camera yourself... this would mean writing your own JPG decoder that would allow you to process this byte[] data in smaller chunks, each chunk one at a time.
Say you won't write your own decoder. :-) That leaves you with 2 options: - Reduce the image size: Subsample - Reduce the image color depth: Dither. Subsample: Create a bitmap from the byte[] data: BitmapFactory.decodeByteArray and set BitmapFactory.Options.inSampleSize to value larger than 1 (prefrrably to a power of 2) Dither: Create a bitmap from the byte[] data that has the RGB_565 encoding and use dithering to avoid banding. Now you have a Bitmap from the BitmapFactory.decodeByteArray call. If creating the other (blending) bitmap would cause OutOfMemory issues, chop up both the camera Bitmap. See Bitmap.createBitmap<http://developer.android.com/reference/android/graphics/Bitmap.html#createBitmap(android.graphics.Bitmap,+int,+int,+int,+int)> (Bitmap<http://developer.android.com/reference/android/graphics/Bitmap.html> source, int x, int y, int width, int height) On Wednesday, April 18, 2012 6:40:51 PM UTC-4, Spooky wrote: > > On Wed, Apr 18, 2012 at 03:28:11PM -0700, Streets Of Boston wrote: > > The size of the JPG/PNG file has almost nothing to do with the size of > the > > corresponding image in memory. > > Hopefully those who HAVE been saying that will read this. > > > An RGB_565 takes 2 bytes per pixel (5+6+5=16bits=2bytes). > > Yes, but you lose color detail...again, that goes directly against the > entire objective of my app. For the "goofy" stuff, sure, RGB_565 is > fine. But for photographic filters (solid color, graduated, split-field, > fog, diffusion, etc. And given their semi-transparency, RGB_565 > definitely isn't a fit for those bitmaps (which don't need to be > full-sized until saving the photos with filters, and then there's only > one bitmap with all of the combined filters).). > > > An ARGB_8888 takes 4 bytes per pixel. This means a 5MPixel image will > > take 5M*2 = 10MByte in RAM when using RGB_565 or 5M*4=20MByte in RAM > > when using ARGB_8888. > > Hmm, here's a thought...is there a bitmap type that I missed, that has > alpha values like ARGB_8888, but only uses 16-bit color? Those > definitely don't need 24-bit color---only the actual photo needs 24-bit. > > > I have an image editor in the market and I managed to process full-sized > > images, reverting back to RGB_565 when necessary. > > My image editor only applies *linear *filters. I.e. filters that modify > > every pixel in an image the same way, regardless of the pixel's position > or > > its neighbors. This allows my app to chop up large images into smaller > ones > > and deal with the smaller ones one by one. If not, i would need, at some > > point in time 2 copies of the image: The original and the modified. > > Can you point me to the right docs, tutorials, etc., to work out how to > do that? > > Thanks, > --jim > > -- > THE SCORE: ME: 2 CANCER: 0 > 73 DE N5IAL (/4) | "My spell checker eloped with a wiccan > spooky1...@gmail.com | and I've not seen it since!" > < Running FreeBSD 7.0 > | > ICBM / Hurricane: | (from news.admin.net-abuse.email) > 30.44406N 86.59909W | > > Android Apps Listing at http://www.jstrack.org/barcodes.html > > -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
