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) Save the byte[] data from the camera into file directly (this is your JPG file). On Wednesday, April 18, 2012 6:02:41 PM UTC-4, JackN wrote: > > Depends on your depth. For 3 bytes per color (24 bit color), a 2592x1944 > is 15 MEGABYTES. > > jpeg aint rle > > > > On Wednesday, April 18, 2012 1:39:39 PM UTC-7, Spooky wrote: > >> On Wed, Apr 18, 2012 at 12:50:41PM -0700, JackN wrote: >> >> > 350 kB jpg? in memory, that could be huge. perhaps even 20 or more MB >> >> [corrected units in the above ... I've never actually SEEN anything that >> can store data in millibits, nor have I seen file sizes meansured in >> bits] >> >> I doubt that. I'm working with full-sized and near-full-sized images >> (3 MP//2048x1536 or 5 MP//2592x1944) and those are around 750 kB and 1.1 >> MB, respectively (give or take a few hundred kB). I can't remember which >> I was working with at the time, but whichever one it was, logcat showed >> the system allocating 10 MB for it. >> >> For a jpeg to be that small, and taket that much memory for a bitmap, it >> would have to be one huge, and extremely plain (solid color, perhaps?) >> to be that compressible. >> >> But those are the size bitmaps I'm running into, trying to give users >> the full resolution of their respective cameras. But processing the >> entire image PLUS FILTERS at the same time is crashing beyond hard >> limits on per-app memory (which, from what I read in an one of several >> dozen old posts while trying to find the answer to my questions, both >> before and after posting here, is 16 MB, period). >> >> I've read that, on 3.0 and up, you can allocate more heap for the image >> (and I've seen in logcat where my A500 does). I've also read that images >> aren't processed in that part of the memory (but like I said...). I've >> read so much conflicting information now it's insane (and I soon will >> be). Some of the Dev Guide that looked helpful even pointed me to a dead >> link **within the dev guide itself**. :-) >> >> And while I'm here, one of the most common answers I've read so far is >> simply "use less memory." >> >> Uh huh. Well, that's exactly what I'm asking how to do, with the >> added desire to allow the user to keep the full resolution. It just >> seems wrong to ask someone using a camera app that's both for the >> serious and goofy types of photography, who has an Android with far >> more than my 5 MP, that they can't even use 5 MP with my app. I >> would be laughing myself out of the Android developer world LONG >> before everyone else got to it (and they would). >> >> To lower memory usage, one of the things I've done is to put in a >> "bmp.recycle();" and "bmp = null;" right after the final usage of >> every bitmap (except the one being returned, which I assume is >> recycled after it's returned). Unfornately, doing this results in >> a Force Close, griping that I've tried to use a bitmap that's already >> been recycled. Meaning (as I understand it, at least) that it's either >> executing lines of code in reverse order, or it's griping about it having >> been recycled in the PREVIOUS use of that method. >> >> I also tried the 3.0+ option, android:largeHeap="true", in the Manifest, >> but still got the same out of memory error. >> >> Perhaps there's some method of processing the photo and filter bitmaps in >> chunks in a way I'm not aware of? Something that doesn't eventually end >> up right back at an eventual out of memory error? Or some other method? >> >> Someone? Anyone? Please..... >> >> Thanks, >> --jim >> >> -- >> THE SCORE: ME: 2 CANCER: 0 >> 73 DE N5IAL (/4) | "Now what *you* need is a proper pint of >> spooky1...@gmail.com | porter poured in a proper pewter porter >> < Running FreeBSD 7.0 > | pot.." >> ICBM / Hurricane: | --Peter Dalgaard in alt.sysadmin.recovery >> 30.44406N 86.59909W | >> >> Android Apps Listing at http://www.jstrack.org/barcodes.htm >> l >> >> -- 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
