[Development] Extending touch semantic information and Qt backends

Ariel Molina ariel at edis.mx
Thu Feb 11 19:33:10 CET 2016


Edward,

I strongly agree with your analysis. Any generalized touch (marker, finger,
pen) has a general elliptic shape defined by a rectangle, when a device
does not support that info, touches are just degenerate squares 0 by 0 and
zero area. But richer devices might provide blob rect and blob angle, blob
unique ID *and* the type of blob: Touch, PenTouch, Blob either uniquely
identified or not (and the source of them if we can dream that far).

Thinking like this we can easily support Normal Fingertouches (non
universally identified Touch with only temporary ID, -null blob area, zero
angle or pressure if not supported-), Makers can be blobs with an ID, area
and angle; palms, hands, a cup of coffee and others are just unidentified
blobs on devices that can recognize them (SUR40?, current optical trackers
and future new devices).

Please correct me, but I see this as paving future support for those recent
haptic devices such as Apple Pen, Wacoms (and Im sure Google has something
in the works for Android).

Ariel



On Thu, Feb 11, 2016 at 8:05 AM, Welbourne Edward <
edward.welbourne at theqtcompany.com> wrote:

> Very much a digression but ...
>
> > TUIO models the touchpoint as a rotated ellipse though, right?  [snip
> > URL] And I think that’s nice, for finger touchpoints at least
> > (although markers could be any shape).  It can be assumed to be the
> > ellipse inscribed in a rect
>
> Traditional graphics always thinks in terms of *coordinate-aligned*
> rectangles, characterised by a width and height with respect to a single
> fixed coordinate system.  This works fine for the classical (vertical
> rectangular) screen and even for most modern tablets, where "rotation"
> may be supported but only in multiples of a quarter turn.  However, once
> you get to the kind of "touch surface as table" that the reactable video
> illustrated - a horizontal round table, no less - there ceases being any
> naturality to any one choice of coordinate alignment.  It's then
> necessary to support all orientations equally well, without privileging
> one of them.
>
> In such a context, either an ellipse or a rectangle can be reduced to a
> centre-point, a semi-major axial vector (orienting it) and a semi-minor
> axis length (at right angles).  Naturally, we can equivalently scale the
> axes by two to drop the semi-s.  There's then an obvious correspondence
> between a rectangle and an ellipse via matching characterisation in
> these terms.  Which you think of that set of parameters as representing
> is then somewhat arbitrary.  The area of contact between a finger and a
> flat surface is closer to elliptical than to rectangular; but there's a
> stronger reason to prefer an ellipse.
>
> Now, I know nothing of the implementation details of touch screens: but
> have to guess that the actual raw data of an object pressing on a screen
> is a noisy mess of pressure signals from nearby sensors.  The natural
> way to process that noisy mess shall be statistically and the natural
> statistical trickery to use for it is going to give you a mean (vector)
> and variance (matrix).  The former is your centre-point; the latter is
> (necessarily, from how it'll be computed from raw data) a symmetric
> positive-definite quadratic form, a.k.a. a metric, which shall be
> diagonalised by some specific choice of coordinates - characterised by
> two perpendicular vectors, one of which we get to construe as semi-major
> axial vector, with the other telling us the semi-minor axis length.  All
> of this would still be true for markers of stranger shapes, thanks to
> the noisy mess of physcal sensor data.  So I'm not surprised to hear
> that a touchpoint ends up represented by these three data - centre,
> major axial vector, minor axis length - or some geometrical entity
> equivalent to them.
>
> While these data can indeed be understood equally as characterising a
> rectangle or an ellipse, coming via a metric makes the ellipse (the
> "unit circle" of the distance associated with the metric) the more
> natural form.  When major and minor axes are close to equal in length,
> the ellipse strongly de-emphasises its incidental orientation, becoming
> completely orientation-agnostic when we get to major = minor, the
> circle.  In contrast, a rectangle retains its sense of orientation all
> the way to that degenerate case, where the square still has a definite
> orientation, albeit modulo quarter turns.
>
> We need an orientation in our representation, to support the case where
> the axial lengths are significantly different, but we need to think of
> that orientation as only relevant in so far as the axial lengths *are*
> significantly different.  Data derived from a metric in the form of
> centre, major axial vector and minor axial size are thus more naturally
> thought of as describing an ellipse.
>
> So let me encourage you to think in terms of ellipses in this modern
> era, as the more natural reading of "centre, major axial vector, minor
> axial size" data, rather than in terms of the rectangles you grew up
> with - they are an artefact of upright rectangular screens.  The tactile
> UI folk rightly prefer a well-rounded future,
>
>         Eddy.
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>



-- 
Ariel Molina R.

http://edis.mx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160211/45a201a2/attachment.html>


More information about the Development mailing list