cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "jbondc@openmv.com" <jbo...@openmv.com>
Subject RE: Camera API
Date Wed, 28 Aug 2013 17:54:11 GMT
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 <raycamde@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" <wjamesjong@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 <john@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?
>> 
> 


Mime
View raw message