cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John M. Wargo" <>
Subject Camera targetWidth & targetHeight
Date Tue, 03 Dec 2013 03:15:06 GMT
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:

Portrait 	Landscape
480x640 	640x480
600x800 	800x600
768x1024 	1024x768
768x1024 	1024x768
768x1024 	1024x768

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

John M. Wargo
@johnwargo <> <>

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