+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
> num
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 P
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
Hey
So, right now on KitKat, the Camera API is super borked. You can't
save to album, since the Media Provider is giving paths that don't
exist, and also you can't actually pull from the album since they
changed the URI encoding and made it a lot more difficult to move from
a Java
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
Can someone explain to me what correctOrientation is supposed to do?
I just spent the last hour or so trying everything I can think of to make this
thing do its voodo on Android and iOS and I can't tell the difference between
photos taken with correctOrientation : true and
correctOrientation :
ser does not expect to be able
to arbitrarily set both.
-James Jong
On Aug 28, 2013, at 7:15 AM, John Wargo wrote:
I've got another silly question. In looking at the Camera API, I see
the following:
targetWidth: Width in pixels to scale image. Must be used with
targetHeight. Aspect rati
th.
-James Jong
On Aug 28, 2013, at 7:15 AM, John Wargo wrote:
I've got another silly question. In looking at the Camera API, I see
the following:
targetWidth: Width in pixels to scale image. Must be used with
targetHeight. Aspect ratio remains constant. (Number)
targetHeight: Height
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
learer.
> > >
> > > On 8/28/13 9:04 AM, "James Jong" wrote:
> > >
> > >> 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 wrote:
> >>
> >>> I've got another silly question.
>> to arbitrarily set both.
>>
>> -James Jong
>>
>> On Aug 28, 2013, at 7:15 AM, John Wargo wrote:
>>
>>> I've got another silly question. In looking at the Camera API, I see
>>> the following:
>>>
>>> targetWidth: Wi
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 wrote:
>
>> I've got another silly question. In looking at the Camera API, I see
>>the
28, 2013, at 7:15 AM, John Wargo wrote:
>
> > I've got another silly question. In looking at the Camera API, I see the
> following:
> >
> > targetWidth: Width in pixels to scale image. Must be used with
> targetHeight. Aspect ratio remains constant. (Number)
&
Wargo wrote:
> I've got another silly question. In looking at the Camera API, I see the
> following:
>
> targetWidth: Width in pixels to scale image. Must be used with targetHeight.
> Aspect ratio remains constant. (Number)
>
> targetHeight: Height in pixels to scale image
I've got another silly question. In looking at the Camera API, I see the
following:
targetWidth: Width in pixels to scale image. Must be used with targetHeight.
Aspect ratio remains constant. (Number)
targetHeight: Height in pixels to scale image. Must be used with targetWidth.
Aspect
This is also dependent on the developer's code being able to detect if
there is a front facing camera, (or ass facing), which means it should
likely happen after we finalize a capabilities api.
I believe the issues Simon mentions are issues regardless. There is
nothing in that issue that states t
If we don't implement a way to specify the front camera we should at
least address the bugs that arrise from the users doing it themselves.
Since taking a picture with a front camera gives you different
orientation values than the back camera it causes problems with how
the image is displayed in th
related: a lot of our roadmap work first depends on finalizing the cli
tools, splitting out the apis, and adding plug man support for most
platforms. Therefore, I see those as priorities.
On 1/8/13 4:57 PM, "Shazron" wrote:
>This is a multi-platform concern:
>https://issues.apache.org/jira/brows
It's api work so I would recommend we wait until we start splitting out
the apis.
On 1/8/13 4:57 PM, "Shazron" wrote:
>This is a multi-platform concern:
>https://issues.apache.org/jira/browse/CB-1683
>
>2.4.0 or we should wait for the audit?
This is a multi-platform concern:
https://issues.apache.org/jira/browse/CB-1683
2.4.0 or we should wait for the audit?
33 matches
Mail list logo
