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