Mailing-List: contact callback-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: callback-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of fil@adobe.com designates
 64.18.1.189 as permitted sender)
From: Filip Maj <fil@adobe.com>
To: "callback-dev@incubator.apache.org" <callback-dev@incubator.apache.org>
Date: Fri, 15 Jun 2012 14:33:04 -0700
Subject: Re: Android Camera Woes
Thread-Topic: Android Camera Woes
Thread-Index: Ac1LPlIqarmQRfWKR0GkRY0GipfEMA==
Message-ID: <CC00F6F0.848F%fil@adobe.com>
In-Reply-To: 
 <CAM1AYQB5GxxnS4WJuv8BOY5V==N6OTTDX5YxvzR=t6fMX7_wPg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/14.2.2.120421
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

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