incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Maj <...@adobe.com>
Subject Re: Android Camera Woes
Date Fri, 15 Jun 2012 21:33:04 GMT
I have a few suggestions, but maybe not all of them would impact the
problems you describe below:

- get rid of DATA_URL. Canvas provides a built-in alternative to getting
this data if necessary.
- get rid of any resizing. Users should be able to do this by dropping the
picture file URI into an image tag and resizing the image tag as necessary.
- possibly consider eliminating quality as well.

On 6/15/12 1:21 PM, "Simon MacDonald" <simon.macdonald@gmail.com> wrote:

>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