incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon MacDonald <simon.macdon...@gmail.com>
Subject Android Camera Woes
Date Fri, 15 Jun 2012 20:21:55 GMT
Hey all,

I've been looking into our Camera woes for the past couple of days.
Regardless of the options we load the image into an Android Bitmap
object. For a 5 MP camera at 2048x1536 the resulting size of the image
in memory is 12 MB. So it is no wonder we get issues like
https://issues.apache.org/jira/browse/CB-910.

I noticed one thing we are doing wrong that I'm going to correct. In
the use case where we ask for a FILE_URI with default quality, default
width and default height we still load the image into memory. I know a
way we can get around doing this and will implement it early next
week. Although this only improves one use case.

In the case where the user asks for a new height or width the image
has to be loaded into a bitmap in order to be scaled and a second
bitmap is created to hold the scaled image. This can be improved if we
remove the ability for the user to specify width/height and replace
that with a scale factor. We can remove the need to load the full
image in memory and only load the scaled image in memory if we only
allow it to be halved, quartered, etc. This will result in a lot less
memory being used.

The third issue is the quality parameter. It is fairly useless. Asking
for the quality to be 80% still requires the entire image to be loaded
in memory before it is processed. The resulting file size is not 20%
smaller than the original and the actual picture "quality" looks
horrible. I do no like this parameter and we should discourage people
from using it.

Anyway, that the state of the onion right now. If anyone knows of some
way to edit the image file in place without having to load it in an
expensive (memory wise) Bitmap object I'm all ears.

Thanks...

Simon Mac Donald
http://hi.im/simonmacdonald

Mime
View raw message