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.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
