These questions have been going around on these boards before :-) And i dealt with these questions as well (I wrote a camera app that can deal with large pictures).
You just have to deal with memory limitations. When you load or create a bitmap, it takes up RAM according to its size and config. If the number of bytes doesn't fit into the app's (process') allowable heap, an OOM will happen. No other way around it. There are ways to mitigate OOMs, but something has to give: - Don't use ARGB_8888, use RGB_565 as a config with dithering. This will reduce image quality. - Subsample. This will reduce image size. - Combination of the two above. - If you are applying only linear transformations to your image data (e.g. you can use a ColorMatrixColorFilter; every pixel in the image is transformed using the same matrix/vector operation), you can chop up your large image into smaller chunks, apply the filters to each chunk and re-assemble the chunks back again into the entire image. - If you are applying other types of transformations, the above is harder to do (e.g. sharpening, blurring, etc; neighboring pixels affect the filter application of a given pixel). - In all cases, if your app needs to run on Android versions lower than 3.0, recycle (large) bitmaps a.s.a.p. and call System.gc() to make sure that your process gets the memory it deserves. On Saturday, July 7, 2012 3:50:12 PM UTC-4, Spooky wrote: > > On Sat, Jul 07, 2012 at 03:41:26PM -0400, Mark Murphy wrote: > > On Sat, Jul 7, 2012 at 3:33 PM, Jim Graham <[email protected]> > wrote: > > > No, but it's my alternative for blending any photographic color > filters > > > (e.g., solid color, graduated, and/or split-field) with the photo, and > > > then doing stuff like brightness, ontrast, color balance, gamma, and > so > > > on, without running into an OOM error. It's that, or limit the image > > > size, which I really hate the idea of forcing users with higher > > > resolution cameras to do, even if only one step down in resolution. > It > > > just doesn't seem right, IMHO. > > > > Off the cuff... > > > > Step #1: Use ActivityManager and getMemoryClass() to determine how big > > your heap size is. > > > > Step #2: Ask the Camera getSupportedPictureSizes(). > > > > Step #3: Choose a picture size based upon the memory class and needs > > of your app. > > But it still doesn't seem like the right thing to do, asking someone to > compromise on image quality in an app that's intended to be for more > serious uses of the camera to begin with.... I'll just keep trying to > find the non-existant (as far as I can tell so far, after a week or two > of searching for it) documentation on the missing C++ bits, etc., > for OpenCV/JNI. I already have the blending and post-processing stuff > done for Java (all except the blending are matrix and convolution matrix > based---the blending uses paint, PorterDuff, and the canvas), but again, > I hit those memory limits... > > Like I said...I'll keep looking. > > Thanks, > --jim > > -- > THE SCORE: ME: 2 CANCER: 0 > 73 DE N5IAL (/4) MiSTie #49997 < Running Mac OS X Lion > > [email protected] ICBM/Hurricane: 30.44406N 86.59909W > > Do not look into waveguide with remaining eye! > > 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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
