On Wed, Apr 18, 2012 at 03:59:23PM -0700, Streets Of Boston wrote:
> 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.
Admittedly, there will probably be some devices that absolutely will face
limits when using the filters (and probably matrix stuff for brightness
and contrast adjustments in post, too) that I'm providing in my app. But
I am determined to miinimize that to the best extent possible. My intent
is to make this a serious camera app, and that means maximizing image
quality relative to the device's camera.
What I'm planning to do, after figuring out exactly HOW I'll be doing the
blending, is to work out the total memory required, and then use either
getLargeMemoryClass() or getMemoryClass() to find out if the user has it.
If they simply can't support it, advise them that the original file was
saved, but the processed one will have to be resized to continue.
I seem to recall, either yesterday (while I was sick and my mind was
really foggy) seeing a suggestion, whether in private e-mail or old
posts, I'm not sure, about saving the jpeg file in chunks, too, and I
REALLY have no idea how to do that.
> Say you won't write your own decoder. :-)
You won't write your own decoder. :-) (sorry, couldn't resist)
> That leaves you with 2 options:
> - Reduce the image size: Subsample
> - Reduce the image color depth: Dither.
I'd rather limit size than color. A smaller, but still having rich, full
color is far more likely to be accepted than a larger, yet lower-quality
image. But I could use a 16-bit (plus Alpha, so somewhere between
RGB_565 and ARGB_8888) for the filters.
> Subsample: Create a bitmap from the byte[] data:
Already doing that for processing with the filters (also bitmaps).
Side question: why, after I'm finished with byte[] data, and I set it
to null, does it still seem to sit there and chew up memory? Also, on
a related note, I have a couple of bitmaps in one method that are
initially re-sized and should be recycled to protect the rest of that
method (only really matters when handling the BIG bitmaps). But...when
I try that, it causes a force close, saying I'm trying to use a bitmap
that has already been recycled (I'd just copied it to another, and
was done with the original...not using it again in the current call
to that method). Ahy idea what's going on there?
> BitmapFactory.decodeByteArray and set
> BitmapFactory.Options.inSampleSize to value larger than 1 (prefrrably
> to a power of 2)
Ok, this is something I'm not familiar with. So does byte[] data
need to hang around, then? Or am I creating a bitmap and tossing
byte[] data? Sorry if I sound like I have no idea what we're talking
about on this part, but frankly, I don't. In the process of getting as
far as I already am on this app, I've learned *FAR* more (so much it's
measured on a log scale) about Android programming than in all of my
previous apps combined...and then some...and I'm still learning, so
please bear [is that the right spelling in this context?] with me.
> Dither: Create a bitmap from the byte[] data that has the RGB_565 encoding
> and use dithering to avoid banding.
Again, RGB_565 + Alpha, whatever that is, will work for the filters, but
not for the photo. I'd rather limit its size if that's the only option.
> 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.
Ok. I already have the filter bitmap in 640x480. Is there a way to
process the larger bitmap pixel-by-pixel, using that smaller one, scaled
up in the math? And, how do I "blend" (add) the color values for each
pixel? Or do I enlarge chunks of the smaller bitmap (in relative-sized
chunks from the small one) to blend with the bigger one?
And here's a question that might work (or might be an incredibly bad
idea). If there's a way to save a raw data file, could I, perhaps,
create the photo's bitmap, split it into chunks (or do those at the
same time?), then save each chunk into a raw data file. Then do the
same for the filter bitmap. Next, call another Activity with the
filenames passed with the Intent, and have it process each pair, one
at a time, save the result, recycle everything, reload the next, and
repeat. And then, load the combined chunk data files, combine into
one bitmap (now I REALLY don't know how I'd do that, unless via paint
and the canvas would work---might still have to load one chunk at a
time and release its data immediately when done with it) until finished,
then save the bitmap to a jpeg, and return from that Activity to the
main activity. Would something like that be A) possible, and B) sane?
> Save the byte[] data from the camera into file directly (this is your JPG
> file).
Wait...I thought we were doing the revisions on the bitmap we made FROM
the byte[] data. Back to confused....but not as much as before. It may
take a few rounds of e-mail, but I'll get it sorted it out.
Thanks---a LOT,
--jim
--
THE SCORE: ME: 2 CANCER: 0
73 DE N5IAL (/4) MiSTie #49997 < Running FreeBSD 7.0 >
spooky1...@gmail.com ICBM/Hurricane: 30.44406N 86.59909W
"Someone ever tries to kill you, you try to kill 'em right back!"
--Mal (Firefly, 1x03, Our Mrs. Reynolds)
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
