cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John M. Wargo" <jwarg...@gmail.com>
Subject Re: Camera targetWidth & targetHeight
Date Tue, 03 Dec 2013 12:34:34 GMT
It occurred to me this morning that I didn't test a scenario where an application deliberately
didn't maintain an appropriate aspect ratio with targetWidth & targetHeight.

I added a button to my app that set targetWidth to 2048 and targetHeight to 768.

On Android I got the following:

Portrait: 768x1024
Landscape: 1024x768

On iOS I got the following:

Portrait: 576x768
Landscape: 1024x768

Not what I expected. So apparently the API grabs the smaller property and applies a set aspect
ratio to the resulting photo rather than try to do something weird. Notice again that on iOS
the API applies the restriction weirdly in portrait.

On 12/2/2013 10:18 PM, Simon MacDonald wrote:
> IIRC on Android if you only specify the width or height it will determine
> what the other value should be by using the same aspect ration as the
> original image.
>
>
> Simon Mac Donald
> http://hi.im/simonmacdonald
>
>
> On Mon, Dec 2, 2013 at 10:15 PM, John M. Wargo <jwargo23@gmail.com> wrote:
>
>> A while back I posted a question regarding Camera targetWidth &
>> targetHeight properties and how they worked. After some discussion, the
>> conclusion I reached was that the documentation couldn't be correct about
>> how it worked since there was no way to determine the camera's resolution
>> with the current API but the docs said I had to provide both parameters.  I
>> said I'd do some testing and I have finally gotten around to completing it.
>> Here's what I discovered:
>>
>> I created an application that allowed me to pass in different values for
>> targetWidth & targetHeight when taking a picture. I tested at the following
>> image sizes: 640x480, 800x600, 1024x768 as well as setting only the
>> targetWidth to 1024 or only the targetHeight to 768.
>>
>> Here's the results:
>>
>> Android
>> Portrait        Landscape
>> 480x640         640x480
>> 600x800         800x600
>> 768x1024        1024x768
>> 768x1024        1024x768
>> 768x1024        1024x768
>>
>>
>>
>> iOS
>> Portrait        Landscape
>> 360x480         640x480
>> 450x600         800x600
>> 576x768         1024x768
>> 2448x3264       3264x2448
>> 2448x3264       3264x2448
>>
>>
>>
>> Windows Phone 8
>> Portrait        Landscape
>> 1836x3264       3264x1836
>> 1836x3264       3264x1836
>> 1836x3264       3264x1836
>> 1836x3264       3264x1836
>> 1836x3264       3264x1836
>>
>>
>> As you can see, Android properly implements the targetWidth & targetHeight
>> properties. On iOS, it supports setting both properties, but not instances
>> where only one is specified. Windows Phone 8 ignores the parameters
>> completely.  On iOS, when you turn the device on its side, the Camera API
>> applies the target width or height to the wrong axis (Android does this
>> well however).
>>
>> I'm trying to test this on a BlackBerry device, but my development
>> environment is giving me fits right now. I'll work on it in the morning and
>> publish my results when I get them.
>>
>> I would suggest that the android implementation is as expected and that
>> the other platforms need their implementations of targetWidth &
>> targetHeight adjusted so it works correctly. The documentation should be
>> updated as well as it's incorrect today specifying that both properties
>> must be provided.
>>
>> If the group doesn't want to support only providing one of the properties,
>> then I would expect that the onError callback is called when only one is
>> provided rather than simply ignoring them as is the case with iOS and
>> Windows Phone.
>>
>> I posted my sample application and a spreadsheet with my results to
>> https://github.com/johnwargo/camera_res_test
>>
>> --
>> John M. Wargo
>> @johnwargo <http://twitter.com/johnwargo>
>> www.johnwargo.com <http://www.johnwargo.com>
>> ------------------------------------------------------------
>> ------------------------------------------------------------
>> ------------------------------------------------------------
>> ------------------------------------------------------------
>> ------------------------------------------------------------
>> ------------------------------------------------------------
>> ------------------------------------------------------------
>> ------------------------------------------------------------
>> ------------------------------------------------------------
>> ------------------------------------------------------------
>> ------------------------------------------------------------
>> ------------------------------------------------------------
>> ------------------------------------------------------------
>> ------------------------------------------------------------
>> ------------------------------------------------------------
>> ------------------------------------------------------------
>> ------------------------------
>>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message