For targetWidth = 2048 , targetHeight=768, does it make sense to have the result picture with width=768,height=1024? That seems odd to me.
-James Jong On Dec 3, 2013, at 7:34 AM, John M. Wargo <[email protected]> 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 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 <[email protected]> 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> >>> ------------------------------------------------------------ >>> ------------------------------------------------------------ >>> ------------------------------------------------------------ >>> ------------------------------------------------------------ >>> ------------------------------------------------------------ >>> ------------------------------------------------------------ >>> ------------------------------------------------------------ >>> ------------------------------------------------------------ >>> ------------------------------------------------------------ >>> ------------------------------------------------------------ >>> ------------------------------------------------------------ >>> ------------------------------------------------------------ >>> ------------------------------------------------------------ >>> ------------------------------------------------------------ >>> ------------------------------------------------------------ >>> ------------------------------------------------------------ >>> ------------------------------ >>> >
