[jira] [Updated] (CB-5942) targetWidth and targetHeight are not being interpreted consistently across platforms
[ https://issues.apache.org/jira/browse/CB-5942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shazron Abdullah updated CB-5942: - Description: 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: h2. Android ||Expected||Portrait||Landscape|| |640x480|480x640|640x480| |800x600|600x800|800x600| |1024x768|768x1024|1024x768| |1024x?|768x1024|1024x768| |?x768|768x1024|1024x768| h2. iOS ||Expected||Portrait||Landscape|| |640x480|360x480|640x480| |800x600|450x600|800x600| |1024x768|576x768|1024x768| |1024x?|2448x3264|3264x2448| |?x768|2448x3264|3264x2448| h2. Windows Phone 8 ||Expected||Portrait||Landscape|| |640x480|1836x3264|3264x1836| |800x600|1836x3264|3264x1836| |1024x768|1836x3264|3264x1836| |1024x?|1836x3264|3264x1836| |?x768|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 The concensus on the dev list is the following: The API should never grow the image The API should shrink the image while maintaining aspect ratio, such that both dimensions of the resized image fit within targetWidth and targetHeight. I would propose as well that the API support only one of the parameters or both - the API should understand enough about the image file to maintain aspect ratio, the developer shouldn't have to tell it. was: 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
[jira] [Updated] (CB-5942) targetWidth and targetHeight are not being interpreted consistently across platforms
[ https://issues.apache.org/jira/browse/CB-5942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John M. Wargo updated CB-5942: -- Description: 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 The concensus on the dev list is the following: The API should never grow the image The API should shrink the image while maintaining aspect ratio, such that both dimensions of the resized image fit within targetWidth and targetHeight. I would propose as well that the API support only one of the parameters or both - the API should understand enough about the image file to maintain aspect ratio, the developer shouldn't have to tell it. was: 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 PortraitLandscape 360x480 640x480 450x600 800x600 576x768 1024x768 2448x3264 3264x2448 2448x3264 3264x2448 Windows Phone 8 PortraitLandscape 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
[jira] [Updated] (CB-5942) targetWidth and targetHeight are not being interpreted consistently across platforms
[ https://issues.apache.org/jira/browse/CB-5942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John M. Wargo updated CB-5942: -- Description: 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 PortraitLandscape 360x480 640x480 450x600 800x600 576x768 1024x768 2448x3264 3264x2448 2448x3264 3264x2448 Windows Phone 8 PortraitLandscape 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 The concensus on the dev list is the following: The API should never grow the image The API should shrink the image while maintaining aspect ratio, such that both dimensions of the resized image fit within targetWidth and targetHeight. I would propose as well that the API support only one of the parameters or both - the API should understand enough about the image file to maintain aspect ratio, the developer shouldn't have to tell it. was: 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 PortraitLandscape 480x640 640x480 600x800 800x600 768x10241024x768 768x10241024x768 768x10241024x768 iOS PortraitLandscape 360x480 640x480 450x600 800x600 576x768 1024x768 2448x3264 3264x2448 2448x3264 3264x2448 Windows Phone 8 PortraitLandscape 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 othe
[jira] [Updated] (CB-5942) targetWidth and targetHeight are not being interpreted consistently across platforms
[ https://issues.apache.org/jira/browse/CB-5942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shazron Abdullah updated CB-5942: - Environment: iOS, WP8 > targetWidth and targetHeight are not being interpreted consistently across > platforms > > > Key: CB-5942 > URL: https://issues.apache.org/jira/browse/CB-5942 > Project: Apache Cordova > Issue Type: Bug > Components: Plugin Camera >Affects Versions: 3.0.0, 3.1.0, 3.2.0 > Environment: iOS, WP8 >Reporter: John M. Wargo > > 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 > PortraitLandscape > 480x640 640x480 > 600x800 800x600 > 768x10241024x768 > 768x10241024x768 > 768x10241024x768 > iOS > PortraitLandscape > 360x480 640x480 > 450x600 800x600 > 576x768 1024x768 > 2448x3264 3264x2448 > 2448x3264 3264x2448 > Windows Phone 8 > PortraitLandscape > 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 > The concensus on the dev list is the following: > The API should never grow the image > The API should shrink the image while maintaining aspect ratio, such that > both dimensions of the resized image fit within targetWidth and targetHeight. > I would propose as well that the API support only one of the parameters or > both - the API should understand enough about the image file to maintain > aspect ratio, the developer shouldn't have to tell it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
