Note that createScaledBitmap may return the same bitmap as the input...
when the input parameters *width *and *height *are the same as the
width/height of your input bitmap:
Change the code as follows (bold part is the changed part):
Bitmap bmp1 = Bitmap.createScaledBitmap(src, width, height, false);
*if (bmp1 != src) {*
src.recycle(); src = null;
*}*
Do a similar thing for bmp2 and dst.
I'm a photographer as well (not professional, though) :)
Using RGB_565 is ok for most purposes. The camera quality of most phones
are not up to snuff yet to really warrant a 8-bit color space. However,
camera quality of some devices is starting to catch up. But for now, people
taking pics with their phones would need no better than RGB_565 processing.
On Thursday, April 19, 2012 11:03:11 PM UTC-4, Spooky wrote:
>
> On Thu, Apr 19, 2012 at 03:22:39PM -0700, Streets Of Boston wrote:
> > " *But there is one big question...why does recycling the bitmaps after
> > their last use still result in a force close, saying that I tried to use
> > them AFTER they were recycled? *"
> >
> > We don't have enough of your code. But suppose you have this code
> executed:
>
> Ok, here's the actual code for the exact part that WAS causing the problem:
>
> public Bitmap mergeBitmaps(Bitmap src, Bitmap dest, int width, int
> height) {
>
> Bitmap bmp1 = Bitmap.createScaledBitmap(src, width, height, false);
> src.recycle() ; src = null;
>
> Bitmap bmp2 = Bitmap.createScaledBitmap(dest, width, height, false);
> dest.recycle() ; dest = null;
>
> And then bmp1 and bmp2 were used from that point on. Note that this code
> has now been deleted. I use src and dest directly. I was originally
> doing resizing at the end here, but that went away, and this code was
> removed (well, the bmp1 and bmp2 parts, and the two recycle()s).
>
> After that, the question was more just to learn why it didn't work as I
> thought it would. Now, I think I understand. By using bmp1 and bmp2, I
> WAS still using src and dest, even though they'd been recycled ... BAM!
> FORCE CLOSE.
>
> And thank you for explaning that to me. I always thought that creating a
> bitmap from another one was creating an entirely new bitmap, not still
> using the old one. Now I know what not to do. :-)
>
> Btw, just FYI, on an old (for this thread) topic: out of curiosity, I
> re-read RGB_565 to find out how many thousands of colors it had, and if
> I might want to go ahead and consider it after all. Then I read this
> (in Bitmap.Config):
>
> "This configuration may be useful when using opaque
> bitmaps that do not require high color fidelity."
>
> There's no way this fits into a camera app primarily geared for serious
> photography, looking at adding diffusion filters to soften faces, fog
> filters (you can do a LOT with a low fog, moderately deep blue filter,
> and the right scene/environment), and so on. Think of it like going to
> any of the planet's beautifyl natural wonders, with a camera. Which
> would you rather have (and this is based on film): a point and shoot
> 35mm with the cheapest and crappiest film you could buy, or a Nikon F4
> 35mm with Kodak Ektar Professional 100 ASA film? Yeah.... :-) I
> thought of that comparison a few hours ago, and it fits, even though it's
> film, not digital[1].
>
> Thanks,
> --jim
>
>
> [1] OT: I still prefer film for some photography, at least, until I
> have the money to get the latest---whatever is the latest at that
> time---Nikon professional-class DSLR. And maybe still even then,
> unless, by that time, digital has more density and color depth
> than pro-quality film like Ektar Pro, which can literally be enlarged
> to WALL sized without a hint of grainyness (pixelation for digital).
> In fact, even its old non-pro predecessor, Ektar 125, which I
> discovered around 1990 or so, could be. I saw it first-hand, and it
> was incredible (and it was a BIG wall). But that is WAY off-topic,
> so I'll end this bit here.
>
> --
> THE SCORE: ME: 2 CANCER: 0
> 73 DE N5IAL (/4) | Peter da Silva: No, try "rm -rf /"
> spooky1...@gmail.com | Dave Aronson: As your life flashes before
> < Running FreeBSD 7.0 > | your eyes, in the unit of time known as an
> ICBM / Hurricane: | ohnosecond.... (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
