Re: Proposal for Hints Information

On 01/25/2012 12:22 AM, Aleksandr Avseyev wrote:
>    I like it except that I'm not sure if aspect ratio should be the 
> highest priority.In real life use cases it seems to be working fine. 
> Say, webcam supports 960x540 and 1600x1200. User sets aspect priority 
> to 16:9 and min height to 1200. It should pick 960x540, right?
If you want to play with aspect ratios, call into a hangout using your 
Android phone, and then turn it sideways.

It's a fun experience, but not everyone will agree it's the greatest UI 
experience one could have.

>
> On Tue, Jan 24, 2012 at 6:57 AM, Cullen Jennings <fluffy@cisco.com 
> <mailto:fluffy@cisco.com>> wrote:
>
>
>     I'm thinking about the uses cases here and let me try a straw man …
>
>     If there is an aspect ratio, specified, meeting that constraint is
>     the highest priority.
>
>     If there is a max height or width set, meeting that constrain is
>     the next highest priority.
>
>     If there is a min height or width set, meeting that constraint is
>     the lowest priority.
>
>     All constraints being meant, select the solution with the largest
>     number of pixels.
>
>
>     For the cases I could think of of being "realistic" use cases -
>     these rules seemed to work. Thoughts on if something as simple of
>     this would not work? different set of rules ?
>
>
>
>     On Jan 24, 2012, at 6:12 , Dan Burnett wrote:
>
>     > This almost makes my point for why selectable configs are best.
>      Authors will always want to control priority.  In fact, I suspect
>     authors will want not just single priority flags but rather an
>     ability to give a priority list, e.g., height_bound is more
>     important than best_aspect, which is more important than
>     fit_height, but width_bound, best_fit, and fit_width are unacceptable.
>     >
>     > -- dan
>     >
>     > On Jan 23, 2012, at 9:41 PM, Aleksandr Avseyev wrote:
>     >
>     >>   I would add priority flags: HEIGHT_BOUND, WIDTH_BOUND or
>     BEST_FIT, BEST_ASPECT, FIT_WIDTH, FIT_HEIGHT. Default priority is
>     pixel count and we don't care if either height or width go out of
>     bound.
>     >>
>     >> On Mon, Jan 23, 2012 at 5:26 PM, Cullen Jennings
>     <fluffy@cisco.com <mailto:fluffy@cisco.com>> wrote:
>     >>
>     >> On Jan 23, 2012, at 15:11 , Aleksandr Avseyev wrote:
>     >>
>     >> >
>     >> > On Mon, Jan 23, 2012 at 8:32 AM, Cullen Jennings
>     <fluffy@cisco.com <mailto:fluffy@cisco.com>> wrote:
>     >> >
>     >> >
>     >> > For Video: ----------------------------
>     >> >
>     >> > min / max height
>     >> >
>     >> > min / max width
>     >> >
>     >> >  Is there any reason not to put height and weight into pairs?
>     From my opinion it makes more sense to specify minRes(w, h) and
>     maxRes(w, h). Aspect ratio is a good idea, but it should be
>     specified on how it works with resolution.
>     >> >
>     >> > ------------------------------
>     >> > Regards, Aleksandr Avseyev (Futurewei Research Lab)
>     >> >
>     >>
>     >> that seems like a reasonable idea but we'd need to figure one
>     more thing out and what is what min and max mine in the case of 2
>     d vector. For example, is 176 by 144 bigger or smaller than 160 by
>     160. What I would propose is that we order them based on the
>     number of pixels. So 176 * 144 = 25344 which is smaller than 160 *
>     160 = 25600. If the number of pixels is the same then we pick the
>     one that is wider is considered bigger.
>     >>
>     >> Does that sound like it would work ?
>     >>
>     >>
>     >>
>     >>
>     >>
>     >> --
>     >>
>     >> ------------------------------
>     >> Regards, Aleksandr Avseyev (Futurewei Research Lab)
>     >> www.pictures2.com <http://www.pictures2.com>
>     >
>
>
>
>
> -- 
>
> ------------------------------
> Regards, Aleksandr Avseyev (Futurewei Research Lab)
> www.pictures2.com <http://www.pictures2.com>