Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cordova.apache.org
Received-SPF: pass (athena.apache.org: domain of john.wargo@sap.com designates
 155.56.66.98 as permitted sender)
From: "Wargo, John" <john.wargo@sap.com>
To: "dev@cordova.apache.org" <dev@cordova.apache.org>
Subject: RE: Camera targetWidth & targetHeight
Thread-Topic: Camera targetWidth & targetHeight
Thread-Index: AQHO79X9lbyZzswj2UCNraPgKXlovJpCINKAgACbXgCAAEMNgIAAUNuAgADoHIA=
Date: Wed, 4 Dec 2013 16:19:02 +0000
Message-ID: 
 <5900F9BCB827854FB01CA94BA718810D1E756CA6@USPHLEMB11A.global.corp.sap>
References: <529D4CBA.3040703@gmail.com>
 <CAM1AYQBwJjGc3KQSEAe7siCvHXyH+wA6F9QcoO=NGpzh35xMag@mail.gmail.com>
 <529DCFDA.5020904@gmail.com>
 <A481F0E2-7C1F-40F4-921E-E90B53815938@gmail.com>
 <CAE6O_-ZH1J35dvkTCtSXR7YU0vRGpqKnGiEpNSj1tq1QPZrMmQ@mail.gmail.com>
In-Reply-To: 
 <CAE6O_-ZH1J35dvkTCtSXR7YU0vRGpqKnGiEpNSj1tq1QPZrMmQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

Actually, I like being able to only apply one property. That is a useful us=
e case for me. We know the camera is going to maintain an aspect ratio when=
 it resizes the image, right? All that matters then is one dimension; aspec=
t ratio takes care of the other one.  I would expect it to be implemented b=
etter though; iOS is applying it to the wrong axis when in portrait mode fo=
r example.=20

John M. Wargo

-----Original Message-----
From: Shazron [mailto:shazron@gmail.com]=20
Sent: Tuesday, December 03, 2013 4:24 PM
To: dev@cordova.apache.org
Subject: Re: Camera targetWidth & targetHeight

Thanks for doing this John.

I think the immediate win is to do this:
"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."

... since this should be done anyway regardless of what is decided.


On Tue, Dec 3, 2013 at 8:34 AM, James Jong <wjamesjong@gmail.com> wrote:

> For targetWidth =3D 2048 , targetHeight=3D768, does it make sense to have=
 the
> result picture with width=3D768,height=3D1024?  That seems odd to me.
>
> -James Jong
>
> On Dec 3, 2013, at 7:34 AM, John M. Wargo <jwargo23@gmail.com> wrote:
>
> > 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 targetHeigh=
t
> 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, t=
he
> >>> 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 th=
is
> >>> 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 th=
at
> >>> 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 properti=
es
> >>> 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>
> >>> ------------------------------------------------------------
> >>> ------------------------------------------------------------
> >>> ------------------------------------------------------------
> >>> ------------------------------------------------------------
> >>> ------------------------------------------------------------
> >>> ------------------------------------------------------------
> >>> ------------------------------------------------------------
> >>> ------------------------------------------------------------
> >>> ------------------------------------------------------------
> >>> ------------------------------------------------------------
> >>> ------------------------------------------------------------
> >>> ------------------------------------------------------------
> >>> ------------------------------------------------------------
> >>> ------------------------------------------------------------
> >>> ------------------------------------------------------------
> >>> ------------------------------------------------------------
> >>> ------------------------------
> >>>
> >
>
>