是否有手势的手势库的变化提高识别? [英] Does having variations of gestures in gesture library improve recognition?

查看:344
本文介绍了是否有手势的手势库的变化提高识别?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我工作的落实手势识别我的应用程序,使用手势Builder创建手势库。我不知道是否有一个手势的多种变化将帮助或阻碍识别(或绩效)。例如,我要承认一个圆形的手势。我将至少有两个版本 - 一个用于顺时针一圈,一为逆时针方向,用同样的语义,使用户不必去想它。不过,我想知道,如果希望节省几个手势,每个方向,例如,不同的半径,或具有不同的形状是足够接近 - 像鸡蛋的形状,椭圆形等,包括不同角度的旋转每一个。任何人有这方面的经验?

I'm working on implementing gesture recognition in my app, using the Gestures Builder to create a library of gestures. I'm wondering if having multiple variations of a gesture will help or hinder recognition (or performance). For example, I want to recognize a circular gesture. I'm going to have at least two variations - one for a clockwise circle, and one for counterclockwise, with the same semantic meaning so that the user doesn't have to think about it. However, I'm wondering if it would be desirable to save several gestures for each direction, for example, of various radii, or with different shapes that are "close enough" - like egg shapes, ellipses, etc., including different angular rotations of each. Anybody have experience with this?

推荐答案

确定,一些experimenation和阅读的Andr​​oid源后,我学到了一点...首先,看来我不一定要担心我的手势库中创建不同的手势来覆盖不同角度旋转或方向我圆形的手势(顺时​​针/逆时针)。缺省情况下,使用GestureStore SEQUENCE_SENSITIVE序列类型(表示的出发点和结束点关系),和ORIENTATION_SENSITIVE的取向方式(即旋转角事项)。但是,这些默认值可以通过'setOrientationStyle(ORIENTATION_INVARIANT)和setSequenceType(SEQUENCE_INVARIANT)所覆盖。

OK, after some experimenation and reading of the android source, I've learned a little... First, it appears that I don't necessarily have to worry about creating different gestures in my gesture library to cover different angular rotations or directions (clockwise/counterclockwise) of my circular gesture. By default, a GestureStore uses a sequence type of SEQUENCE_SENSITIVE (meaning that the starting point and ending points matter), and an orientation style of ORIENTATION_SENSITIVE (meaning that the rotational angle matters). However, these defaults can be overridden with 'setOrientationStyle(ORIENTATION_INVARIANT)' and setSequenceType(SEQUENCE_INVARIANT).

此外,从​​当SEQUENCE_SENSITIVE时,只有单次行程手势目前允许和ORIENTATION_SENSITIVE和ORIENTATION_INVARIANT仅供SEQUENCE_SENSITIVE手势源代码中的注释......引用。

Furthermore, to quote from the comments in the source... "when SEQUENCE_SENSITIVE is used, only single stroke gestures are currently allowed" and "ORIENTATION_SENSITIVE and ORIENTATION_INVARIANT are only for SEQUENCE_SENSITIVE gestures".

有趣的是,ORIENTATION_SENSITIVE似乎意味着更多的不仅仅是倾向问题。它的值是2,与它和一些相关的(无证)常数相关的注释暗示你可以要求不同的灵敏度水平。

Interestingly, ORIENTATION_SENSITIVE appears to mean more than just "orientation matters". It's value is 2, and the comments associated with it and some related (undocumented) constants imply that you can request different levels of sensitivity.

// at most 2 directions can be recognized
public static final int ORIENTATION_SENSITIVE = 2;
// at most 4 directions can be recognized
static final int ORIENTATION_SENSITIVE_4 = 4;
// at most 8 directions can be recognized
static final int ORIENTATION_SENSITIVE_8 = 8;

在通话期间向GestureLibary.recognize(),该取向类型值(1,2,4,或8)被传递到GestureUtils.minimumCosineDistance()作为参数numOrientations,由此一些计算所执行的是我的上述薪酬等级(见下文)。如果有人可以解释这一点,我很感兴趣。我得到的,它是计算两个举手投足之间的角度差,但我不知道这是使用numOrientations参数的方式。我的期望是,如果我指定的值是2,找到手势和姿态的B两种变化之间的最小距离 - 一个变体是正常B,而另一个是乙转身180度。因此,我希望值8会考虑8变化的B,间隔45度。然而,尽管我不完全理解下面的数学,它不看我像4个或8个直接用于任何计算一个numOrientations值,但大于2的值也导致不同的code路径。也许这就是为什么这些其他值没有证件。

During a call to GestureLibary.recognize(), the orientation type value (1, 2, 4, or 8) is passed through to GestureUtils.minimumCosineDistance() as the parameter numOrientations, whereupon some calculations are performed that are above my pay grade (see below). If someone can explain this, I'm interested. I get that it is calculating the angular difference between two gestures, but I don't understand the way it's using the numOrientations parameter. My expectation is that if I specify a value of 2, it finds the minimum distance between gesture A and two variations of gesture B -- one variation being "normal B", and the other being B spun around 180 degrees. Thus, I would expect a value of 8 would consider 8 variations of B, spaced 45 degrees apart. However, even though I don't fully understand the math below, it doesn't look to me like a numOrientations value of 4 or 8 is used directly in any calculations, although values greater than 2 do result in a distinct code path. Maybe that's why those other values are undocumented.

/**
 * Calculates the "minimum" cosine distance between two instances.
 * 
 * @param vector1
 * @param vector2
 * @param numOrientations the maximum number of orientation allowed
 * @return the distance between the two instances (between 0 and Math.PI)
 */
static float minimumCosineDistance(float[] vector1, float[] vector2, int numOrientations) {
    final int len = vector1.length;
    float a = 0;
    float b = 0;
    for (int i = 0; i < len; i += 2) {
        a += vector1[i] * vector2[i] + vector1[i + 1] * vector2[i + 1];
        b += vector1[i] * vector2[i + 1] - vector1[i + 1] * vector2[i];
    }
    if (a != 0) {
        final float tan = b/a;
        final double angle = Math.atan(tan);
        if (numOrientations > 2 && Math.abs(angle) >= Math.PI / numOrientations) {
            return (float) Math.acos(a);
        } else {
            final double cosine = Math.cos(angle);
            final double sine = cosine * tan; 
            return (float) Math.acos(a * cosine + b * sine);
        }
    } else {
        return (float) Math.PI / 2;
    }
}

根据我的阅读中,我的理论认为,最简单,最好的方法是将有一个存储的圆形姿态,设置序列类型和取向,以不变的。这样一来,任何圆形应该匹配pretty的好,不管方向或方向。所以,我想这一点,它没有返回高分(约25至70的范围)为pretty的任何东西远程类似一个圆。然而,它也返回的20左右的手势甚至不接近圆形(水平线,V形等)的分数。所以,我并没有感觉良好,应该是什么比赛,什么不应该的分离。什么似乎是工作最好是有两个存储的手势,每个方向一个,并在与ORIENTATION_INVARIANT结合使用SEQUENCE_SENSITIVE。这是给我的2.5或更高的分数任何东西隐约圆形,但分数低于1(在所有的或不匹配)的手势不是圆形的。

Based on my reading, I theorized that the simplest and best approach would be to have one stored circular gesture, setting the sequence type and orientation to invariant. That way, anything circular should match pretty well, regardless of direction or orientation. So I tried that, and it did return high scores (in the range of about 25 to 70) for pretty much anything remotely resembling a circle. However, it also returned scores of 20 or so for gestures that were not even close to circular (horizontal lines, V shapes, etc.). So, I didn't feel good about the separation between what should be matches and what should not. What seems to be working best is to have two stored gestures, one in each direction, and using SEQUENCE_SENSITIVE in conjunction with ORIENTATION_INVARIANT. That's giving me scores of 2.5 or higher for anything vaguely circular, but scores below 1 (or no matches at all) for gestures that are not circular.

这篇关于是否有手势的手势库的变化提高识别?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆