subject:"Re\: \[android\-developers\] need help working with very large \(photo\) bitmaps"

Re: [android-developers] need help working with very large (photo) bitmaps

2012-04-22 Thread Jim Graham

(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

2012-04-22 Thread Massycat


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

2012-04-20 Thread Jim Graham

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

2012-04-20 Thread Streets Of Boston

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

2012-04-19 Thread Jim Graham

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

2012-04-19 Thread Streets Of Boston

"  *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

2012-04-19 Thread JackN

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

2012-04-19 Thread Jim Graham

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

2012-04-19 Thread Streets Of Boston

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 fro

Re: [android-developers] need help working with very large (photo) bitmaps

2012-04-18 Thread Jim Graham

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

Re: [android-developers] need help working with very large (photo) bitmaps

2012-04-18 Thread Streets Of Boston


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.createBitmap
(Bitmap 
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

2012-04-18 Thread Streets Of Boston

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.createBitmap(Bitmap
 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| po

RE: [android-developers] need help working with very large (photo) bitmaps

2012-04-18 Thread Tommy Hartz

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

2012-04-18 Thread Jim Graham

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

2012-04-18 Thread Kostya Vasilyev


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

2012-04-18 Thread Jim Graham

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

2012-04-18 Thread Streets Of Boston

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

2012-04-18 Thread Jim Graham

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

2012-04-18 Thread Kostya Vasilyev


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

2012-04-18 Thread Jim Graham

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

2012-04-18 Thread JackN

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

2012-04-18 Thread Kostya Vasilyev


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

2012-04-18 Thread Jim Graham

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

2012-04-18 Thread JackN

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

2012-04-18 Thread ANKUR GOEL

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

Re: [android-developers] need help working with very large (photo) bitmaps

Re: [android-developers] need help working with very large (photo) bitmaps

Re: [android-developers] need help working with very large (photo) bitmaps

Re: [android-developers] need help working with very large (photo) bitmaps

Re: [android-developers] need help working with very large (photo) bitmaps

Re: [android-developers] need help working with very large (photo) bitmaps

Re: [android-developers] need help working with very large (photo) bitmaps

Re: [android-developers] need help working with very large (photo) bitmaps

Re: [android-developers] need help working with very large (photo) bitmaps

Re: [android-developers] need help working with very large (photo) bitmaps

Re: [android-developers] need help working with very large (photo) bitmaps

RE: [android-developers] need help working with very large (photo) bitmaps

Re: [android-developers] need help working with very large (photo) bitmaps

Re: [android-developers] need help working with very large (photo) bitmaps

Re: [android-developers] need help working with very large (photo) bitmaps

Re: [android-developers] need help working with very large (photo) bitmaps

Re: [android-developers] need help working with very large (photo) bitmaps

Re: [android-developers] need help working with very large (photo) bitmaps

Re: [android-developers] need help working with very large (photo) bitmaps

Re: [android-developers] need help working with very large (photo) bitmaps

Re: [android-developers] need help working with very large (photo) bitmaps

Re: [android-developers] need help working with very large (photo) bitmaps

Re: [android-developers] need help working with very large (photo) bitmaps

Re: [android-developers] need help working with very large (photo) bitmaps

25 matches

Site Navigation

Mail list logo

Footer information