You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by John Wargo <jo...@johnwargo.com> on 2013/08/28 13:15:18 UTC
Camera API
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 ratio remains constant. (Number)
I'm not getting why targetWidth MUST be used with targetHeight (and visa versa) when aspect ratio remains constant. If aspect ratio remains constant, then setting one automatically forces the other - that's the whole point of maintaining aspect ratio, right? If the API is maintaining aspect ratio while sizing the image, then forcing the developer to specify both parameters is simply wasted work.
What am I missing here?
Re: Camera API
Posted by Max Woghiren <ma...@chromium.org>.
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 <wj...@gmail.com> 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 <jo...@johnwargo.com> 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. Must be used with
> targetWidth. Aspect ratio remains constant. (Number)
> >
> > I'm not getting why targetWidth MUST be used with targetHeight (and visa
> versa) when aspect ratio remains constant. If aspect ratio remains
> constant, then setting one automatically forces the other - that's the
> whole point of maintaining aspect ratio, right? If the API is maintaining
> aspect ratio while sizing the image, then forcing the developer to specify
> both parameters is simply wasted work.
> >
> > What am I missing here?
>
>
Re: Camera API
Posted by "John M. Wargo" <jw...@gmail.com>.
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 get to it before then, then I'll make that my first doc contribution.
On 8/28/2013 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
>
>
> On Thu, Aug 29, 2013 at 12:04 AM, James Jong <wj...@gmail.com> wrote:
>
>> 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 we
>> would break backwards compatibility there.
>>
>> -James Jong
>>
>> On Aug 28, 2013, at 10:16 AM, Ray Camden <ra...@adobe.com> wrote:
>>
>>> 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 platform that provides a way to pass a H and W that act as a
>>> bounding box, so if I use 150x150, my final result will be no bigger than
>>> 150x150, but possibly smaller in order to maintain aspect ratio. If that
>>> is what PG is doing, then the docs should clearly spell that out. Maybe
>> it
>>> is assumed by "Aspect ratio remains constant", but I think it could be
>>> clearer.
>>>
>>> On 8/28/13 9:04 AM, "James Jong" <wj...@gmail.com> 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 <jo...@johnwargo.com> 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. Must be used with
>>>>> targetWidth. Aspect ratio remains constant. (Number)
>>>>>
>>>>> I'm not getting why targetWidth MUST be used with targetHeight (and
>>>>> visa versa) when aspect ratio remains constant. If aspect ratio remains
>>>>> constant, then setting one automatically forces the other - that's the
>>>>> whole point of maintaining aspect ratio, right? If the API is
>>>>> maintaining aspect ratio while sizing the image, then forcing the
>>>>> developer to specify both parameters is simply wasted work.
>>>>>
>>>>> What am I missing here?
>>
Re: Camera API
Posted by Carlos Santana <cs...@gmail.com>.
+1 on documenting existing implementation first
On Wed, Aug 28, 2013 at 12:15 PM, Shazron <sh...@gmail.com> 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
>
>
> On Thu, Aug 29, 2013 at 12:04 AM, James Jong <wj...@gmail.com> wrote:
>
> > 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 we
> > would break backwards compatibility there.
> >
> > -James Jong
> >
> > On Aug 28, 2013, at 10:16 AM, Ray Camden <ra...@adobe.com> wrote:
> >
> > > 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 platform that provides a way to pass a H and W that act as a
> > > bounding box, so if I use 150x150, my final result will be no bigger
> than
> > > 150x150, but possibly smaller in order to maintain aspect ratio. If
> that
> > > is what PG is doing, then the docs should clearly spell that out. Maybe
> > it
> > > is assumed by "Aspect ratio remains constant", but I think it could be
> > > clearer.
> > >
> > > On 8/28/13 9:04 AM, "James Jong" <wj...@gmail.com> 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 <jo...@johnwargo.com> 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. Must be used with
> > >>> targetWidth. Aspect ratio remains constant. (Number)
> > >>>
> > >>> I'm not getting why targetWidth MUST be used with targetHeight (and
> > >>> visa versa) when aspect ratio remains constant. If aspect ratio
> remains
> > >>> constant, then setting one automatically forces the other - that's
> the
> > >>> whole point of maintaining aspect ratio, right? If the API is
> > >>> maintaining aspect ratio while sizing the image, then forcing the
> > >>> developer to specify both parameters is simply wasted work.
> > >>>
> > >>> What am I missing here?
> > >>
> > >
> >
> >
>
--
Carlos Santana
<cs...@gmail.com>
Re: Camera API
Posted by "John M. Wargo" <jw...@gmail.com>.
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, the parameters did not affect the resulting picture. The documentation says as well that the parameters must be used in conjunction with each other and that aspect ratio is maintained. This further reinforces that these options cannot work as documented (which my testing has proven) since it doesn't make sense that you have to set both height and width while at the same time maintaining an aspect ratio for the picture. If it truly was maintaining aspect ratio, then I'd expect that only one of the values would be able to be set. To truly maintain aspect ratio, you'd only be able to set either targetHeight or targetWidth, not both."
Anyway, I'll do some testing again and post the results.
On 8/28/2013 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
>
>
> On Thu, Aug 29, 2013 at 12:04 AM, James Jong <wj...@gmail.com> wrote:
>
>> 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 we
>> would break backwards compatibility there.
>>
>> -James Jong
>>
>> On Aug 28, 2013, at 10:16 AM, Ray Camden <ra...@adobe.com> wrote:
>>
>>> 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 platform that provides a way to pass a H and W that act as a
>>> bounding box, so if I use 150x150, my final result will be no bigger than
>>> 150x150, but possibly smaller in order to maintain aspect ratio. If that
>>> is what PG is doing, then the docs should clearly spell that out. Maybe
>> it
>>> is assumed by "Aspect ratio remains constant", but I think it could be
>>> clearer.
>>>
>>> On 8/28/13 9:04 AM, "James Jong" <wj...@gmail.com> 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 <jo...@johnwargo.com> 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. Must be used with
>>>>> targetWidth. Aspect ratio remains constant. (Number)
>>>>>
>>>>> I'm not getting why targetWidth MUST be used with targetHeight (and
>>>>> visa versa) when aspect ratio remains constant. If aspect ratio remains
>>>>> constant, then setting one automatically forces the other - that's the
>>>>> whole point of maintaining aspect ratio, right? If the API is
>>>>> maintaining aspect ratio while sizing the image, then forcing the
>>>>> developer to specify both parameters is simply wasted work.
>>>>>
>>>>> What am I missing here?
>>
Re: Camera API
Posted by Shazron <sh...@gmail.com>.
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 <wj...@gmail.com> wrote:
> 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 we
> would break backwards compatibility there.
>
> -James Jong
>
> On Aug 28, 2013, at 10:16 AM, Ray Camden <ra...@adobe.com> wrote:
>
> > 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 platform that provides a way to pass a H and W that act as a
> > bounding box, so if I use 150x150, my final result will be no bigger than
> > 150x150, but possibly smaller in order to maintain aspect ratio. If that
> > is what PG is doing, then the docs should clearly spell that out. Maybe
> it
> > is assumed by "Aspect ratio remains constant", but I think it could be
> > clearer.
> >
> > On 8/28/13 9:04 AM, "James Jong" <wj...@gmail.com> 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 <jo...@johnwargo.com> 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. Must be used with
> >>> targetWidth. Aspect ratio remains constant. (Number)
> >>>
> >>> I'm not getting why targetWidth MUST be used with targetHeight (and
> >>> visa versa) when aspect ratio remains constant. If aspect ratio remains
> >>> constant, then setting one automatically forces the other - that's the
> >>> whole point of maintaining aspect ratio, right? If the API is
> >>> maintaining aspect ratio while sizing the image, then forcing the
> >>> developer to specify both parameters is simply wasted work.
> >>>
> >>> What am I missing here?
> >>
> >
>
>
RE: Camera API
Posted by "jbondc@openmv.com" <jb...@openmv.com>.
The way I handle this server-side is using strings:
[100x100] - means a "bounding box", resize so that width & height <= 100
100x[100] - means a fixed 100 width, height varies according to aspect ratio
[100]x100 - means a fixed 100 height, width varies according to aspect ratio
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:wjamesjong@gmail.com]
Sent: Wednesday, August 28, 2013 12:05 PM
To: dev@cordova.apache.org
Subject: Re: Camera API
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 we would break backwards compatibility there.
-James Jong
On Aug 28, 2013, at 10:16 AM, Ray Camden <ra...@adobe.com> wrote:
> 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 platform that provides a way to pass a H and W
> that act as a bounding box, so if I use 150x150, my final result will
> be no bigger than 150x150, but possibly smaller in order to maintain
> aspect ratio. If that is what PG is doing, then the docs should
> clearly spell that out. Maybe it is assumed by "Aspect ratio remains
> constant", but I think it could be clearer.
>
> On 8/28/13 9:04 AM, "James Jong" <wj...@gmail.com> 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 <jo...@johnwargo.com> 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. Must be used with
>>> targetWidth. Aspect ratio remains constant. (Number)
>>>
>>> I'm not getting why targetWidth MUST be used with targetHeight (and
>>> visa versa) when aspect ratio remains constant. If aspect ratio
>>> remains constant, then setting one automatically forces the other -
>>> that's the whole point of maintaining aspect ratio, right? If the
>>> API is maintaining aspect ratio while sizing the image, then forcing
>>> the developer to specify both parameters is simply wasted work.
>>>
>>> What am I missing here?
>>
>
Re: Camera API
Posted by James Jong <wj...@gmail.com>.
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 we would break backwards compatibility there.
-James Jong
On Aug 28, 2013, at 10:16 AM, Ray Camden <ra...@adobe.com> wrote:
> 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 platform that provides a way to pass a H and W that act as a
> bounding box, so if I use 150x150, my final result will be no bigger than
> 150x150, but possibly smaller in order to maintain aspect ratio. If that
> is what PG is doing, then the docs should clearly spell that out. Maybe it
> is assumed by "Aspect ratio remains constant", but I think it could be
> clearer.
>
> On 8/28/13 9:04 AM, "James Jong" <wj...@gmail.com> 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 <jo...@johnwargo.com> 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. Must be used with
>>> targetWidth. Aspect ratio remains constant. (Number)
>>>
>>> I'm not getting why targetWidth MUST be used with targetHeight (and
>>> visa versa) when aspect ratio remains constant. If aspect ratio remains
>>> constant, then setting one automatically forces the other - that's the
>>> whole point of maintaining aspect ratio, right? If the API is
>>> maintaining aspect ratio while sizing the image, then forcing the
>>> developer to specify both parameters is simply wasted work.
>>>
>>> What am I missing here?
>>
>
Re: Camera API
Posted by Ray Camden <ra...@adobe.com>.
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 platform that provides a way to pass a H and W that act as a
bounding box, so if I use 150x150, my final result will be no bigger than
150x150, but possibly smaller in order to maintain aspect ratio. If that
is what PG is doing, then the docs should clearly spell that out. Maybe it
is assumed by "Aspect ratio remains constant", but I think it could be
clearer.
On 8/28/13 9:04 AM, "James Jong" <wj...@gmail.com> 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 <jo...@johnwargo.com> 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. Must be used with
>>targetWidth. Aspect ratio remains constant. (Number)
>>
>> I'm not getting why targetWidth MUST be used with targetHeight (and
>>visa versa) when aspect ratio remains constant. If aspect ratio remains
>>constant, then setting one automatically forces the other - that's the
>>whole point of maintaining aspect ratio, right? If the API is
>>maintaining aspect ratio while sizing the image, then forcing the
>>developer to specify both parameters is simply wasted work.
>>
>> What am I missing here?
>
Re: Camera API
Posted by James Jong <wj...@gmail.com>.
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 <jo...@johnwargo.com> 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. Must be used with targetWidth. Aspect ratio remains constant. (Number)
>
> I'm not getting why targetWidth MUST be used with targetHeight (and visa versa) when aspect ratio remains constant. If aspect ratio remains constant, then setting one automatically forces the other - that's the whole point of maintaining aspect ratio, right? If the API is maintaining aspect ratio while sizing the image, then forcing the developer to specify both parameters is simply wasted work.
>
> What am I missing here?