Re: [android-developers] need help working with very large (photo) bitmaps
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? Have a look at BitmapRegionDecoderhttp://developer.android.com/reference/android/graphics/BitmapRegionDecoder.html which should allow you to load a region of an image, process it and save the result without loading the entire image into memory. It is available in API level 10 and above. -- 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
Re: [android-developers] need help working with very large (photo) bitmaps
(re-sending ... when I sent this before, the list was down due to having exceeded its maximum number of recipients ... something I've never heard of any e-mail list doing...and I've been around Listservs and other list varieties for decades) On Wed, Apr 18, 2012 at 03:20:31PM -0700, Massycat wrote: 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? Have a look at BitmapRegionDecoder http://developer.android.com/reference/android/graphics/BitmapRegionDecoder.html which should allow you to load a region of an image, process it and save the result without loading the entire image into memory. Thanks. That should be a BIG help. It is available in API level 10 and above. Ouch. Oh well, I doubt many Froyo phones have more than a 3 MP camera, anyways. Of course, they also probably (based on my phone) have a lot less memory, too. :-( Thanks, either way---it WILL be useful. --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 sigh, once upon a time T-1 was fast --seen in alt.sysadmin.net-abuse.email 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
Re: [android-developers] need help working with very large (photo) bitmaps
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
Re: [android-developers] need help working with very large (photo) bitmaps
On Fri, Apr 20, 2012 at 06:27:18AM -0700, Streets Of Boston wrote:
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.
Except for one minor detail you missed: those are examples that WERE
problems, before I changed the location where I was setting the size
of the bitmaps for the end of the app (moved that to the end), and
both bmp1 and bmp2 no longer exist. :-)
I'm a photographer as well (not professional, though) :)
I'm not a pro, either, but I was taught by one while I was in 16SOW
Intelligence (he was a professional before cross-training into Intel).
I learned a lot. :-) I learned about Ektar, however, somewhere around
1990, with the old non-pro Ektar line, and when I found out that my old
favorite, Ektar 125, was now Ektar Pro 100, I had my favorite film back.
:-)
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.
True on both. But don't forget tablets and the newer phones running ICS.
Better cameras are, as you say, increasing in number with newer,
higher-quality devices.
I'm not building this for the past...I'm building it with an eye toward
the future, and MY tablet (Acer Iconia A500 ... should get ICS sometime
starting around the end of next week) is only 5 MP, but it has great
color.
Besides, I KNOW I saw an old post from someone who described saving
chunks of the file to files (not jpeg, just raw data) and then, I think
it was in another process spawned by the app, processing and saving the
huge image. I'd do the same for the image, recycle it, then create,
split, and save the chunks of the filter...then process in the other
process, keeping only the main image and one tiny chunk at a time in
memory, and finally, save it from the second process.
I don't know how to DO that yet, but I will. Throughout this entire
app, the fact that I haven't known how to do something hasn't stopped
me yet (and I've made big progress blasting through those would-be
blockades), and it's not going to now. (As I mentioned in another
post, I've learned many times more working on this app than all of
my other apps combined, and that pace hasn't slowed down yet, and
I don't mind that a bit.)
But for now, people taking pics with their phones would need no better
than RGB_565 processing.
True. But then, I draw a definite line between taking pictures and
photography. And, like I would imagine most photography hobbiests/pros
do, I do both. So I'm making this app for both (but I'm keeping the
great color). You can adjust the image size to anything your device's
camera will support (and I'm assuming that the device will have adequate
memory to process photos from that camera, given android:largeHeap=true
set in the manifest and Android 3.0+). But if not, it'll soon be smart
enough to detect that, and re-size automatically as needed. But it
won't happen today. My brain is already screaming at me as it is. Any
more time doing much of anything, it'll be an all-out Migraine, and I'll
lose several days, at a minimum (as always, cancer #1, blah blah blah).
Later,
--jim
--
THE SCORE: ME: 2 CANCER: 0
73 DE N5IAL (/4)MiSTie #49997 Running FreeBSD 7.0
spooky1...@gmail.comICBM/Hurr.: 30.44406N 86.59909W
The iPad is a status symbol for yuppies. The Android
is for people who actually want something that works.
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
Re: [android-developers] need help working with very large (photo) bitmaps
First, ignore this sentence below from my previous answer entirely: Save the byte[] data from the camera into file directly (this is your JPG file). (It was a left-over chunk of my initial answer) The 'byte[] data' still takes up memory, because the caller (the Android SDK code that calls the onPictureTaken) still has hold of this byte-array. Setting data=null won't free that memory because only your code release reference to it, not the caller's code. You can save the raw data of the camera's Bitmap (the bitmap returned from decodeByteArray) by calling Bitmap.getPixels a few times (saving the raw data in chunks) or by calling Bitmap.copyPixelsToBuffer. On Wednesday, April 18, 2012 7:58:36 PM UTC-4, Spooky wrote: On Wed, Apr 18, 2012 at 03:59:23PM -0700, Streets Of Boston wrote: Dealing with ARGB_ 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_) 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
Re: [android-developers] need help working with very large (photo) bitmaps
On Thu, Apr 19, 2012 at 06:25:12AM -0700, Streets Of Boston wrote: First, ignore this sentence below from my previous answer entirely: Save the byte[] data from the camera into file directly (this is your JPG file). (It was a left-over chunk of my initial answer) Ah, that explains it. :-) The 'byte[] data' still takes up memory, because the caller (the Android SDK code that calls the onPictureTaken) still has hold of this byte-array. Setting data=null won't free that memory because only your code release reference to it, not the caller's code. Ohhh, yeah, I hadn't thought about that. Damn. Not much I can do about that, then. You can save the raw data of the camera's Bitmap (the bitmap returned from decodeByteArray) by calling Bitmap.getPixels a few times (saving the raw data in chunks) or by calling Bitmap.copyPixelsToBuffer. That's basically what I came up with. This basically just flashed across my brain this morning, and is a combination of ideas I'd been looking at. It goes something like this: 1) if the device can handle this much, convert the original byte[] array to a bitmap (easy). if not, re-size, notify the user, and deal with it. 2) assuming we got past #1, split the file into vertical chunks using Bitmap chunk1; // so each can be recycled immediately after use Bitmap chunk2; Bitmap chunkn; chunk1 = createBitmap(src, 0, 0, width, height/n); // save the chunk to a raw data file here chunk1.recycle(); chunk1 = null; and so on for all n chunks. 3) recycle the original photo image; 4) create the bitmap for the filter and repeat step 2 for it. 5) re-use the bitmap from 4 (or recycle it and make another new one) for the combined image, then, one at a time, recover the saved bitmap chunks and use paint/canvas to re-build them, and then immediately recycle the chunk once it's no longer needed. 6) Save the new photo 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? Oh, and steps 5 and 6 may need to be done in a new process, if I can figure out how to do that (or if someone here will point me to the appropriate reference in the dev guide). So, how does that sound? Thanks, --jim -- THE SCORE: ME: 2 CANCER: 0 73 DE N5IAL (/4)| Tux (E Cat): DS B+Wd Y 6 Y L+++ W+ C++/C++ I+++ spooky1...@gmail.com| T++ A E H+ S V- F++ Q+++ P/P+ B++ PA+ PL SC--- Running FreeBSD 7.0 | ICBM / Hurricane: | Tiggerbelle: DS W+S+Bts % 1.5 X L W C+++/C+ 30.44406N 86.59909W | I+++ T A E++ H S++ V+++ Q+++ P B++ PA++ PL+ SC 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
Re: [android-developers] need help working with very large (photo) bitmaps
it ok, youll get it. you just have some conceptual errors. On Wednesday, April 18, 2012 3:20:56 PM UTC-7, Spooky wrote: On Wed, Apr 18, 2012 at 03:02:41PM -0700, JackN wrote: Depends on your depth. For 3 bytes per color (24 bit color), a 2592x1944 is 15 MEGABYTES. Again ... READ THE FOLLOWING (with corrected units): 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] Now let's come back to this. Depends on your depth. For 3 bytes per color (24 bit color), a 2592x1944 is 15 MEGABYTES. Well, then, since I was replying to the above post, and we're side-tracked by jpegs, not the bitmaps that I'm asking about how best to handle to allow full resolution (if that's even possible), if the above is true, then ARGB_ must not be 24-bit color, because again, NONE of my 5 MP ARGB_ photos have been over around 1.3--1.4 MB. Note that I did NOT say 15 MB. And if that IS true, the developer's guide needs to be corrected, because I seem to recall it saying that ARGB_ IS 24-bit color. Personally, though, I think your jpeg size of 15 MB is on the high end, and the dev guide is right. Again, just to make sure...I was responding to a post about JPEG sizes, NOT BITMAP SIZES. And I am NOT pulling these file sizes out of my ass, I'm getting them directly from jpeg images in /mnt/sdcard/DCIM/camera. Later, --jim -- 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
Re: [android-developers] need help working with very large (photo) bitmaps
*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: Bitmap bitmap1 = new BitmapFactory.decode.(); ... ... Bitmap bitmap2 = bitmap1; ... ... bitmap1.recycle(); ... ... bitmap2.getWidth(); // kaboom: You're using an already recycled bitmap. In other words, you're assigning the same Bitmap instance to more than one variable or field and you are using one variable to recycle() the bitmap. If the code handling the other variables/fields doesn't know about the fact that recycle() already has been called, handling these other variables/fields may result in a force close (bitmap already recycled). You can call 'bitmap.isRecycled()' if you don't keep track of it yourself. On Thursday, April 19, 2012 9:38:28 AM UTC-4, Spooky wrote: On Thu, Apr 19, 2012 at 06:25:12AM -0700, Streets Of Boston wrote: First, ignore this sentence below from my previous answer entirely: Save the byte[] data from the camera into file directly (this is your JPG file). (It was a left-over chunk of my initial answer) Ah, that explains it. :-) The 'byte[] data' still takes up memory, because the caller (the Android SDK code that calls the onPictureTaken) still has hold of this byte-array. Setting data=null won't free that memory because only your code release reference to it, not the caller's code. Ohhh, yeah, I hadn't thought about that. Damn. Not much I can do about that, then. You can save the raw data of the camera's Bitmap (the bitmap returned from decodeByteArray) by calling Bitmap.getPixels a few times (saving the raw data in chunks) or by calling Bitmap.copyPixelsToBuffer. That's basically what I came up with. This basically just flashed across my brain this morning, and is a combination of ideas I'd been looking at. It goes something like this: 1) if the device can handle this much, convert the original byte[] array to a bitmap (easy). if not, re-size, notify the user, and deal with it. 2) assuming we got past #1, split the file into vertical chunks using Bitmap chunk1; // so each can be recycled immediately after use Bitmap chunk2; Bitmap chunkn; chunk1 = createBitmap(src, 0, 0, width, height/n); // save the chunk to a raw data file here chunk1.recycle(); chunk1 = null; and so on for all n chunks. 3) recycle the original photo image; 4) create the bitmap for the filter and repeat step 2 for it. 5) re-use the bitmap from 4 (or recycle it and make another new one) for the combined image, then, one at a time, recover the saved bitmap chunks and use paint/canvas to re-build them, and then immediately recycle the chunk once it's no longer needed. 6) Save the new photo 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? Oh, and steps 5 and 6 may need to be done in a new process, if I can figure out how to do that (or if someone here will point me to the appropriate reference in the dev guide). So, how does that sound? Thanks, --jim -- THE SCORE: ME: 2 CANCER: 0 73 DE N5IAL (/4)| Tux (E Cat): DS B+Wd Y 6 Y L+++ W+ C++/C++ I+++ spooky1...@gmail.com| T++ A E H+ S V- F++ Q+++ P/P+ B++ PA+ PL SC--- Running FreeBSD 7.0 | ICBM / Hurricane: | Tiggerbelle: DS W+S+Bts % 1.5 X L W C+++/C+ 30.44406N 86.59909W | I+++ T A E++ H S++ V+++ Q+++ P B++ PA++ PL+ SC 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
Re: [android-developers] need help working with very large (photo) bitmaps
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
Re: [android-developers] need help working with very large (photo) bitmaps
Even i am loading 350 kb image its giving out of memory . I have image in drawable folder and setting the image in java code .:( On Tue, Apr 17, 2012 at 5:08 PM, Jim Graham spooky1...@gmail.com wrote: The question about blending methods resolved itself when I switched to making the bitmaps for filters in the app. But one question still remains, and I need help with this one. When trying to blend the full-size camera image with an equal-size bitmap for the filter, unless I reduce the image size, I get an out of memory error. I really would like to allow users to get the maximum resolution possible. I start by converting the photo image from byte[] data to bitmap (for blending with the filter bitmap) and then immediately setting data to null. That doesn't seem to help at all. I have tried a combination of bmp.release(); and bmp = null;, which only results in a Force Close. It looks like this: // create full-sized filters instead of 640x480 Bitmap bmp1 = Bitmap.createScaledBitmap(src, width, height, false); // src.recycle() ; src = null; Bitmap bmp2 = Bitmap.createScaledBitmap(dest, width, height, false); // dest.recycle() ; dest = null; The intent being to release the memory used as quickly as possible in the method, rather than waiting until I finish completely with blending them. Unfortunately, if those are uncommented, the result is a Force Close. The Force Close gripes that I'm trying to use a bitmap that's already been recycled...but I don't use those bitmaps (src and dest) again. I also looked into the idea of splitting the task into chunks, but ultimately, there is still a huge amount of data ... right back where I started: out of memory error // Force Close. :-( Can anyone please let me how I can save these at full-size (that is, if there IS another way). If there isn't another way, I would at least appreciate that, then I can at least determine the maximum based on the device's available memory and reduce the image size before causing a force close. Thanks, --jim -- THE SCORE: ME: 2 CANCER: 0 73 DE N5IAL (/4)MiSTie #49997 Running FreeBSD 7.0 spooky1...@gmail.comICBM/Hurr.: 30.44406N 86.59909W Now what *you* need is a proper pint of porter poured in a proper pewter porter pot.. --Peter Dalgaard in alt.sysadmin.recovery 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 -- 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
Re: [android-developers] need help working with very large (photo) bitmaps
350 kb jpg? in memory, that could be huge. perhaps even 20 or more mbs On Wednesday, April 18, 2012 3:29:46 AM UTC-7, ANKUR1486 wrote: Even i am loading 350 kb image its giving out of memory . I have image in drawable folder and setting the image in java code .:( On Tue, Apr 17, 2012 at 5:08 PM, Jim Graham spooky1...@gmail.com wrote: The question about blending methods resolved itself when I switched to making the bitmaps for filters in the app. But one question still remains, and I need help with this one. When trying to blend the full-size camera image with an equal-size bitmap for the filter, unless I reduce the image size, I get an out of memory error. I really would like to allow users to get the maximum resolution possible. I start by converting the photo image from byte[] data to bitmap (for blending with the filter bitmap) and then immediately setting data to null. That doesn't seem to help at all. I have tried a combination of bmp.release(); and bmp = null;, which only results in a Force Close. It looks like this: // create full-sized filters instead of 640x480 Bitmap bmp1 = Bitmap.createScaledBitmap(src, width, height, false); // src.recycle() ; src = null; Bitmap bmp2 = Bitmap.createScaledBitmap(dest, width, height, false); // dest.recycle() ; dest = null; The intent being to release the memory used as quickly as possible in the method, rather than waiting until I finish completely with blending them. Unfortunately, if those are uncommented, the result is a Force Close. The Force Close gripes that I'm trying to use a bitmap that's already been recycled...but I don't use those bitmaps (src and dest) again. I also looked into the idea of splitting the task into chunks, but ultimately, there is still a huge amount of data ... right back where I started: out of memory error // Force Close. :-( Can anyone please let me how I can save these at full-size (that is, if there IS another way). If there isn't another way, I would at least appreciate that, then I can at least determine the maximum based on the device's available memory and reduce the image size before causing a force close. Thanks, --jim -- THE SCORE: ME: 2 CANCER: 0 73 DE N5IAL (/4)MiSTie #49997 Running FreeBSD 7.0 spooky1...@gmail.comICBM/Hurr.: 30.44406N 86.59909W Now what *you* need is a proper pint of porter poured in a proper pewter porter pot.. --Peter Dalgaard in alt.sysadmin.recovery 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 -- 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
Re: [android-developers] need help working with very large (photo) bitmaps
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
Re: [android-developers] need help working with very large (photo) bitmaps
On 04/19/2012 12:39 AM, Jim Graham wrote: 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. What color depth are your images at? 3 MP (milli pixels?) at 24 bit per pixel, RGB_888, is 9 megabytes. 5 millipixels at 24 bit is 15 megabytes. Not 750 kB and 1.1 MB. -- K -- 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
Re: [android-developers] need help working with very large (photo) bitmaps
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
Re: [android-developers] need help working with very large (photo) bitmaps
On Thu, Apr 19, 2012 at 01:55:18AM +0400, Kostya Vasilyev wrote: On 04/19/2012 12:39 AM, Jim Graham wrote: 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. What color depth are your images at? ARGB_. Again, when working on a camera app that's intended as much for serious photography as the goofy side, why shoot myself in the foot by immediately throwing image quality out the window? 3 MP (milli pixels?) at 24 bit per pixel, RGB_888, is 9 megabytes. No...the person who replied had written it as mb ... I corrected it before replying to it. I don't think there is such thing as a mp (or a mb, for that matter ... and if there is, I'd LOVE to know what use it is). 5 millipixels at 24 bit is 15 megabytes. I think you meant MP. :-) Not 750 kB and 1.1 MB. And since he'd referred to JPG sizes, that's what *I* was referring to, not bitmap sizes (I think I included bitmap sizes in there, as well, but specified bitmap, not jpeg. And yes, I did two samples, one at each resolution, both saved as a JPG, and those WERE the respective file sizes. I didn't just dream those up. Oh, and *NONE* of the photos I've taken, even at 5 MP, ended up being 15 MB jpegs (at least, none so far). Later, --jim -- THE SCORE: ME: 2 CANCER: 0 73 DE N5IAL (/4)| My spell checker eloped with a wiccan spooky1...@gmail.com| and I've not seen it since! Running FreeBSD 7.0 | ICBM / Hurricane: |(from news.admin.net-abuse.email) 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
Re: [android-developers] need help working with very large (photo) bitmaps
I'm not saying you dreamed those up, sorry, no offence meant. But since we seem to be discussing memory usage, not disk usage, the compressed size is irrelevant. And 5 megapixels at RGB_ is 32 bits per pixel or 20 megabytes in RAM, if stored as an uncompressed pixel array. -- K On 04/19/2012 02:07 AM, Jim Graham wrote: Not 750 kB and 1.1 MB. And since he'd referred to JPG sizes, that's what*I* was referring to, not bitmap sizes (I think I included bitmap sizes in there, as well, but specified bitmap, not jpeg. And yes, I did two samples, one at each resolution, both saved as a JPG, and those WERE the respective file sizes. I didn't just dream those up. Oh, and*NONE* of the photos I've taken, even at 5 MP, ended up being 15 MB jpegs (at least, none so far). -- 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
Re: [android-developers] need help working with very large (photo) bitmaps
On Wed, Apr 18, 2012 at 03:02:41PM -0700, JackN wrote: Depends on your depth. For 3 bytes per color (24 bit color), a 2592x1944 is 15 MEGABYTES. Again ... READ THE FOLLOWING (with corrected units): 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] Now let's come back to this. Depends on your depth. For 3 bytes per color (24 bit color), a 2592x1944 is 15 MEGABYTES. Well, then, since I was replying to the above post, and we're side-tracked by jpegs, not the bitmaps that I'm asking about how best to handle to allow full resolution (if that's even possible), if the above is true, then ARGB_ must not be 24-bit color, because again, NONE of my 5 MP ARGB_ photos have been over around 1.3--1.4 MB. Note that I did NOT say 15 MB. And if that IS true, the developer's guide needs to be corrected, because I seem to recall it saying that ARGB_ IS 24-bit color. Personally, though, I think your jpeg size of 15 MB is on the high end, and the dev guide is right. Again, just to make sure...I was responding to a post about JPEG sizes, NOT BITMAP SIZES. And I am NOT pulling these file sizes out of my ass, I'm getting them directly from jpeg images in /mnt/sdcard/DCIM/camera. Later, --jim -- 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
Re: [android-developers] need help working with very large (photo) bitmaps
The size of the JPG/PNG file has almost nothing to do with the size of the corresponding image in memory. An RGB_565 takes 2 bytes per pixel (5+6+5=16bits=2bytes). An ARGB_ takes 4 bytes per pixel. This means a 5MPixel image will take 5M*2 = 10MByte in RAM when using RGB_565 or 5M*4=20MByte in RAM when using ARGB_. I have an image editor in the market and I managed to process full-sized images, reverting back to RGB_565 when necessary. My image editor only applies *linear *filters. I.e. filters that modify every pixel in an image the same way, regardless of the pixel's position or its neighbors. This allows my app to chop up large images into smaller ones and deal with the smaller ones one by one. If not, i would need, at some point in time 2 copies of the image: The original and the modified. On Wednesday, April 18, 2012 6:07:54 PM UTC-4, Spooky wrote: On Thu, Apr 19, 2012 at 01:55:18AM +0400, Kostya Vasilyev wrote: On 04/19/2012 12:39 AM, Jim Graham wrote: 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. What color depth are your images at? ARGB_. Again, when working on a camera app that's intended as much for serious photography as the goofy side, why shoot myself in the foot by immediately throwing image quality out the window? 3 MP (milli pixels?) at 24 bit per pixel, RGB_888, is 9 megabytes. No...the person who replied had written it as mb ... I corrected it before replying to it. I don't think there is such thing as a mp (or a mb, for that matter ... and if there is, I'd LOVE to know what use it is). 5 millipixels at 24 bit is 15 megabytes. I think you meant MP. :-) Not 750 kB and 1.1 MB. And since he'd referred to JPG sizes, that's what *I* was referring to, not bitmap sizes (I think I included bitmap sizes in there, as well, but specified bitmap, not jpeg. And yes, I did two samples, one at each resolution, both saved as a JPG, and those WERE the respective file sizes. I didn't just dream those up. Oh, and *NONE* of the photos I've taken, even at 5 MP, ended up being 15 MB jpegs (at least, none so far). Later, --jim -- THE SCORE: ME: 2 CANCER: 0 73 DE N5IAL (/4)| My spell checker eloped with a wiccan spooky1...@gmail.com| and I've not seen it since! Running FreeBSD 7.0 | ICBM / Hurricane: |(from news.admin.net-abuse.email) 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
Re: [android-developers] need help working with very large (photo) bitmaps
On Thu, Apr 19, 2012 at 02:19:54AM +0400, Kostya Vasilyev wrote: I'm not saying you dreamed those up, sorry, no offence meant. But since we seem to be discussing memory usage, not disk usage, the compressed size is irrelevant. Thank you. My point exactly. And 5 megapixels at RGB_ is 32 bits per pixel or 20 megabytes in RAM, if stored as an uncompressed pixel array. Again, my point exactly. A couple of posts got this thread severely side-tracked, which is getting really annoying, as I'm seriously asking for help on the issue I originally posted about[1] in this thread, not stupid jpeg sizes. Later, --jim [1] trying to find out if there's a way to process photo and filter bitmaps in chunks, and possibly save them in chunks, as well, or perhaps use some other method, to allow users to keep their maximum resolution, at 24-bit color, not lousy 16-bit color, and *DEFINITELY* not, as I saw suggested in one of the many old posts I read, reducing the resolution to work with it, and then raising it back up to full resolution, presumably thinking that the lost resolution would just magically restore itself. :-) -- THE SCORE: ME: 2 CANCER: 0 73 DE N5IAL (/4)| My spell checker eloped with a wiccan spooky1...@gmail.com| and I've not seen it since! Running FreeBSD 7.0 | ICBM / Hurricane: |(from news.admin.net-abuse.email) 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
Re: [android-developers] need help working with very large (photo) bitmaps
On 04/19/2012 02:29 AM, Jim Graham wrote: [1] trying to find out if there's a way to process photo and filter bitmaps in chunks, and possibly save them in chunks, as well, or perhaps use some other method, to allow users to keep their maximum resolution, at 24-bit color, not lousy 16-bit color, In that case... What Streets of Boston said. And if your filters need some amount of neighbouring pixels, you may be able to use overlapping slices, provided you're real careful with how you do the calculations in the overlapping parts. and*DEFINITELY* not, as I saw suggested in one of the many old posts I read, reducing the resolution to work with it, and then raising it back up to full resolution, presumably thinking that the lost resolution would just magically restore itself.:-) Um, I don't think such magic exists. Not in computers, anyway :) -- K -- 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
Re: [android-developers] need help working with very large (photo) bitmaps
On Wed, Apr 18, 2012 at 03:28:11PM -0700, Streets Of Boston wrote: The size of the JPG/PNG file has almost nothing to do with the size of the corresponding image in memory. Hopefully those who HAVE been saying that will read this. An RGB_565 takes 2 bytes per pixel (5+6+5=16bits=2bytes). Yes, but you lose color detail...again, that goes directly against the entire objective of my app. For the goofy stuff, sure, RGB_565 is fine. But for photographic filters (solid color, graduated, split-field, fog, diffusion, etc. And given their semi-transparency, RGB_565 definitely isn't a fit for those bitmaps (which don't need to be full-sized until saving the photos with filters, and then there's only one bitmap with all of the combined filters).). An ARGB_ takes 4 bytes per pixel. This means a 5MPixel image will take 5M*2 = 10MByte in RAM when using RGB_565 or 5M*4=20MByte in RAM when using ARGB_. Hmm, here's a thought...is there a bitmap type that I missed, that has alpha values like ARGB_, but only uses 16-bit color? Those definitely don't need 24-bit color---only the actual photo needs 24-bit. I have an image editor in the market and I managed to process full-sized images, reverting back to RGB_565 when necessary. My image editor only applies *linear *filters. I.e. filters that modify every pixel in an image the same way, regardless of the pixel's position or its neighbors. This allows my app to chop up large images into smaller ones and deal with the smaller ones one by one. If not, i would need, at some point in time 2 copies of the image: The original and the modified. Can you point me to the right docs, tutorials, etc., to work out how to do that? Thanks, --jim -- THE SCORE: ME: 2 CANCER: 0 73 DE N5IAL (/4)| My spell checker eloped with a wiccan spooky1...@gmail.com| and I've not seen it since! Running FreeBSD 7.0 | ICBM / Hurricane: |(from news.admin.net-abuse.email) 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
RE: [android-developers] need help working with very large (photo) bitmaps
Jumping in kind of late here, but if memory is a huge deal couldn't you pass the image to a web service that will then handle all the manipulation then return the image URL, download it ,save it then clean up the file from the server via another REST request? And do this on images larger than X. -Original Message- From: android-developers@googlegroups.com [mailto:android-developers@googlegroups.com] On Behalf Of Jim Graham Sent: Wednesday, April 18, 2012 6:41 PM To: android-developers@googlegroups.com Subject: Re: [android-developers] need help working with very large (photo) bitmaps On Wed, Apr 18, 2012 at 03:28:11PM -0700, Streets Of Boston wrote: The size of the JPG/PNG file has almost nothing to do with the size of the corresponding image in memory. Hopefully those who HAVE been saying that will read this. An RGB_565 takes 2 bytes per pixel (5+6+5=16bits=2bytes). Yes, but you lose color detail...again, that goes directly against the entire objective of my app. For the goofy stuff, sure, RGB_565 is fine. But for photographic filters (solid color, graduated, split-field, fog, diffusion, etc. And given their semi-transparency, RGB_565 definitely isn't a fit for those bitmaps (which don't need to be full-sized until saving the photos with filters, and then there's only one bitmap with all of the combined filters).). An ARGB_ takes 4 bytes per pixel. This means a 5MPixel image will take 5M*2 = 10MByte in RAM when using RGB_565 or 5M*4=20MByte in RAM when using ARGB_. Hmm, here's a thought...is there a bitmap type that I missed, that has alpha values like ARGB_, but only uses 16-bit color? Those definitely don't need 24-bit color---only the actual photo needs 24-bit. I have an image editor in the market and I managed to process full-sized images, reverting back to RGB_565 when necessary. My image editor only applies *linear *filters. I.e. filters that modify every pixel in an image the same way, regardless of the pixel's position or its neighbors. This allows my app to chop up large images into smaller ones and deal with the smaller ones one by one. If not, i would need, at some point in time 2 copies of the image: The original and the modified. Can you point me to the right docs, tutorials, etc., to work out how to do that? Thanks, --jim -- THE SCORE: ME: 2 CANCER: 0 73 DE N5IAL (/4)| My spell checker eloped with a wiccan spooky1...@gmail.com| and I've not seen it since! Running FreeBSD 7.0 | ICBM / Hurricane: |(from news.admin.net-abuse.email) 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 -- 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
Re: [android-developers] need help working with very large (photo) bitmaps
Dealing with ARGB_ 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. Say you won't write your own decoder. :-) That leaves you with 2 options: - Reduce the image size: Subsample - Reduce the image color depth: Dither. Subsample: Create a bitmap from the byte[] data: BitmapFactory.decodeByteArray and set BitmapFactory.Options.inSampleSize to value larger than 1 (prefrrably to a power of 2) Dither: Create a bitmap from the byte[] data that has the RGB_565 encoding and use dithering to avoid banding. 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. See Bitmap.createBitmaphttp://developer.android.com/reference/android/graphics/Bitmap.html#createBitmap(android.graphics.Bitmap, int, int, int, int)(Bitmaphttp://developer.android.com/reference/android/graphics/Bitmap.html source, int x, int y, int width, int height) Save the byte[] data from the camera into file directly (this is your JPG file). On Wednesday, April 18, 2012 6:02:41 PM UTC-4, JackN wrote: 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
Re: [android-developers] need help working with very large (photo) bitmaps
Dealing with ARGB_ 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. Say you won't write your own decoder. :-) That leaves you with 2 options: - Reduce the image size: Subsample - Reduce the image color depth: Dither. Subsample: Create a bitmap from the byte[] data: BitmapFactory.decodeByteArray and set BitmapFactory.Options.inSampleSize to value larger than 1 (prefrrably to a power of 2) Dither: Create a bitmap from the byte[] data that has the RGB_565 encoding and use dithering to avoid banding. 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. See Bitmap.createBitmaphttp://developer.android.com/reference/android/graphics/Bitmap.html#createBitmap(android.graphics.Bitmap,+int,+int,+int,+int) (Bitmaphttp://developer.android.com/reference/android/graphics/Bitmap.html source, int x, int y, int width, int height) On Wednesday, April 18, 2012 6:40:51 PM UTC-4, Spooky wrote: On Wed, Apr 18, 2012 at 03:28:11PM -0700, Streets Of Boston wrote: The size of the JPG/PNG file has almost nothing to do with the size of the corresponding image in memory. Hopefully those who HAVE been saying that will read this. An RGB_565 takes 2 bytes per pixel (5+6+5=16bits=2bytes). Yes, but you lose color detail...again, that goes directly against the entire objective of my app. For the goofy stuff, sure, RGB_565 is fine. But for photographic filters (solid color, graduated, split-field, fog, diffusion, etc. And given their semi-transparency, RGB_565 definitely isn't a fit for those bitmaps (which don't need to be full-sized until saving the photos with filters, and then there's only one bitmap with all of the combined filters).). An ARGB_ takes 4 bytes per pixel. This means a 5MPixel image will take 5M*2 = 10MByte in RAM when using RGB_565 or 5M*4=20MByte in RAM when using ARGB_. Hmm, here's a thought...is there a bitmap type that I missed, that has alpha values like ARGB_, but only uses 16-bit color? Those definitely don't need 24-bit color---only the actual photo needs 24-bit. I have an image editor in the market and I managed to process full-sized images, reverting back to RGB_565 when necessary. My image editor only applies *linear *filters. I.e. filters that modify every pixel in an image the same way, regardless of the pixel's position or its neighbors. This allows my app to chop up large images into smaller ones and deal with the smaller ones one by one. If not, i would need, at some point in time 2 copies of the image: The original and the modified. Can you point me to the right docs, tutorials, etc., to work out how to do that? Thanks, --jim -- THE SCORE: ME: 2 CANCER: 0 73 DE N5IAL (/4)| My spell checker eloped with a wiccan spooky1...@gmail.com| and I've not seen it since! Running FreeBSD 7.0 | ICBM / Hurricane: |(from news.admin.net-abuse.email) 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
Re: [android-developers] need help working with very large (photo) bitmaps
On Wed, Apr 18, 2012 at 03:59:23PM -0700, Streets Of Boston wrote: Dealing with ARGB_ 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_) 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
