+1.
Users are confused regarding what to use when.
+1 on Camera API needing audit/rewrite or us updating the Media Capture
plugin with the new w3c API and adding our extensions to it for Camera
(somehow)
On Tue, Jan 21, 2014 at 6:24 PM, Andrew Grieve wrote:
> Agree that Camera pretty much needs a re-write (or a good audit). The
> number of bu
Agree that Camera pretty much needs a re-write (or a good audit). The
number of bugs for it is really piling up. AFAICT, Camera is a useful API,
and Capture is useful for video/audio, but not really useful for pictures.
On Tue, Jan 21, 2014 at 7:00 PM, Brian LeRoux wrote:
> it is perhaps not wi
it is perhaps not with some irony that the Media Capture API as implemented
in ChromeView is a direct descendant of our Capture API which is now out of
date.
The inventory:
- Camera API Plugin (non standard but offers more flexability than the W3C
spec)
- Capture API Plugin (out of date thus non-
Here's the test app: https://github.com/johnwargo/camera_correctOrientation
I ran some tests on Android and orientation is 1 (instead of 0 on iOS) I put
some screen shots in the repository to show what I'm seeing.
On 12/5/2013 2:16 PM, purplecabbage wrote:
Looking at the code for ios, correctO
Looking at the code for ios, correctOrientation doesn't modify exif, it rotates
image bits.
Can you share your test app John?
Sent from my iPhone
> On Dec 5, 2013, at 7:42 AM, "John M. Wargo" wrote:
>
> That makes sense. As I only have this iOS 7 device, can someone do a quick
> test on an
That makes sense. As I only have this iOS 7 device, can someone do a quick test
on an older version of the OS?
On 12/5/2013 9:51 AM, Andrew Grieve wrote:
One explanation is that the iOS camera now always rotates the image for you?
On Thu, Dec 5, 2013 at 9:11 AM, John M. Wargo wrote:
Jesse,
One explanation is that the iOS camera now always rotates the image for you?
On Thu, Dec 5, 2013 at 9:11 AM, John M. Wargo wrote:
> Jesse,
>
> I've been thinking about what you said and I'm not getting it. I created
> an app that has three buttons, one takes a picture without
> correctOrientati
Jesse,
I've been thinking about what you said and I'm not getting it. I created an app
that has three buttons, one takes a picture without correctOrientation even
defined, another sets correctOrientation to true while the last one sets
correctOrientation to false.
When I look at the photos on
Jesse,
Thanks for providing that information.
I downloaded an EXIF property viewer and notice that with correctOrientation
missing or set to false, there are 18 EXIF properties in the file. When I
enable correctOrientation, another 30 EXIF properties are added to the file
(for a total of 48).
It definitely does something, you just may not notice it.
If you try to display an image you took in your app on iOS in any image
viewer that does not correctly interpret exif, then the picture will still
display correctly.
If you remove the code, it will not.
@purplecabbage
risingj.com
On Wed,
I can't get it to do anything on iOS, so I think it's broken.
Any chance someone can do a quick test to confirm my suspicion? Probably need
to remove it from the docs if it doesn't do anything.
On 12/4/2013 8:41 PM, Jesse wrote:
It appears to do nothing, except on iOS.
It is listed as supporte
I believe it was meant to be used with WebViews that don't render jpegs
according to the orientation in their EXIF data.
Quite possible that it solves a problem that no longer exists. If so, it
would be great to get rid of it.
On Wed, Dec 4, 2013 at 8:47 PM, John M. Wargo wrote:
> Josh,
>
> Th
Josh,
That's the PhoneGap 1.7 docs you linked - when you look at the Cordova 3.2 docs
(http://docs.phonegap.com/en/3.2.0/cordova_camera_camera.md.html#cameraOptions),
it does not list _any_ issues with correctOrientation on Android or iOS. I
expect it not to work on Windows Phone because it's
It appears to do nothing, except on iOS.
It is listed as supported on iOS and Android, and back in 1.7, it was iOS
only,
Android does this:
this.correctOrientation = args.getBoolean(8);
iOS uses it after the image is captured, and calls
imageCorrectedForCaptureOrientation
[1] which rotates it acc
John wrote:
> Can someone explain to me what correctOrientation is supposed to do?
http://docs.phonegap.com/en/1.7.0/cordova_camera_camera.md.html
Lists a bunch of platforms that don't implement it.
My guess is that some older platforms wouldn't automatically switch between
portrait and landsc
I went back and looked at the manuscript for PhoneGap Essentials and back then
(a year and a half ago) I had tested this and wrote the following:
"The targetHeight & targetWidth parameters are supposed to control the height and
width of the image obtained using getPicture. In my testing though,
I could spend some time working through the permutations on a few platforms
(Android, BB 10, iOS and Windows Phone), but will be a while before I can get
to it - I've got a day job and I'm trying to finish writing a book with three
chapters to go and a deadline approaching.
If nobody else can
io
There's cases where those 3 are useful, would be nice if it could be done
client side consistently.
-Original Message-
From: James Jong [mailto:wjamesj...@gmail.com]
Sent: Wednesday, August 28, 2013 12:05 PM
To: dev@cordova.apache.org
Subject: Re: Camera API
Several ways we cou
+1 on documenting existing implementation first
On Wed, Aug 28, 2013 at 12:15 PM, Shazron wrote:
> IMO first step would be that we find out what the existing implementations
> actually do, and doc them
> do our standard deprecation dance and implement the new shiny and correct
> functionality
>
IMO first step would be that we find out what the existing implementations
actually do, and doc them
do our standard deprecation dance and implement the new shiny and correct
functionality
On Thu, Aug 29, 2013 at 12:04 AM, James Jong wrote:
> Several ways we could go here. One is to improve th
Several ways we could go here. One is to improve the documentation. iOS
chooses the larger image size. I'm not sure if all the platforms do it the
same way. I'd be happy to update the doc if it's all the same. Second is to
modify the implementation to only require either W or H. Note that
As a user though, that doesn't necessarily make sense. You are saying,
"You must give me a H and W, but I'm going to maintain the aspect ratio no
matter what." Given that, which side is "corrected" if I pass a H and W
that do not maintain the aspect ratio? Do we document it? I've worked on
another
I would expect, if anything, that specifying only one of the two dimensions
would be desired. I'm guessing one overrides the other if both are
specified but don't conform to the aspect ratio; that should probably be in
the docs.
On Wed, Aug 28, 2013 at 10:04 AM, James Jong wrote:
> You're righ
You're right that it could be calculated based on one or the other. The code
expects both today. I think the point is to be clear that the aspect ratio is
maintained, so that the user does not expect to be able to arbitrarily set both.
-James Jong
On Aug 28, 2013, at 7:15 AM, John Wargo wrot
25 matches
Mail list logo
