access to unfiltered gaze point data in the Tobii Stream Engine

[twentythree]

First of all, as a developer I love the stream engine. One thing that’s sorely missing though is access to unfiltered gaze data (or lightly filtered in the EyeX TX_GAZEPOINTDATAMODE_LIGHTLYFILTERED sense), which we need for some of our usecases. Is this on the roadmap?

[Grant [Tobii]]

Hi @twentythree, glad to hear you are enjoying using the Stream Engine API with the Tobii Core SDK.

Indeed within the Gaze Point Data this is already lightly filtered @ https://tobii.github.io/stream_engine/#tobii_streamsh
under the section ‘tobii_gaze_point_subscribe’

This is essentially the full raw data without any fixation filter applied to it, so I am not certain to which level of unfiltered data you are looking for… perhaps you meant if we will supply a fixation filter algorithm with the stream engine? I am afraid that is not currently in the pipeline but I can pass along your request for consideration.

In any event, if you could please clarify the request I would be more than happy to proceed. Thanks.

[twentythree]

So far we’ve been doing our own fixation detection (we are aware of the fixation data available via the EyeX SDK, but we don’t use it widely). We haven’t evaluated yet whether that still works with the data we get out of the StreamEngine. If no, we will probably need fixation data from the stream engine, yes.

But what I’m looking for is a way to configure the level of filtering/smoothing used. These graphs contain two seconds of gaze data simultaneously collected via ExeY SDK (TX_GAZEPOINTDATAPARAMS: {TX_GAZEPOINTDATAMODE_LIGHTLYFILTERED}) and StreamEngine for comparison. The TSE data is actually really nice for most of our usecases (and may save us CPU we previously spent on smoothing), but for some we may need that extra bit of responsiveness currently only available to us through the EyeX SDK’s API (specifically this bit).

[Grant [Tobii]]

Hi @twentythree, thank you very much for the detailed reply and the graphs.

Indeed, the filter implementations were different across both SDK’s. For your information, the C4 filtering algorithm was changed some versions ago on the firmware, so you might get better results by ensuring to run the latest firmware version just in case you are not already.

In any event, I am afraid that full unfiltered raw data is only available for via the Tobii Pro SDK in conjunction with a Pro license purchasable through us. Please let me know if you would be interested in this. Apologies for the disappointing news.

[vwgx3]

Hello,

having read this interesting post I still am not sure about the conclusions to draw from it.

My ultimate goal would actually be to have a constant sampling rate with the EyeX, as the constant sampling rate would make gaze velocities accessible which I am interested in.

But I understood that the EyeX is not a product designed for a use case where this would typically matter, and that there are other models (Pro series) that do that.

As I am still in a PoC phase and not having options to switch the eye scanner type immediately, i am trying to workaround it for the time being, by compensating for the “missing”/dropped samples. And this would be easier the more evenly the distribution of the samples along the time axis would be.

From the examination twentythree did so well and my own test measurements, it seems like the StreamEngine and the unfiltered gaze data stream of the Interaction API are “better” in this regards than the lightly filtered stream, where “better” actually means: handling validity of samples differently, resulting in more ore less frames to be excluded from being submitted by the tracker.

I havn’t been able in my own measurements to pinpoint how “StreamEngine” and “unfiltered” compare to each other, because i have no options to feed both stacks with the same input signal.

Therefore I wonder:
1) Is there a general classification possible for both gaze data streams (StreamEngine, “Interaction-API(unfiltered)”) in terms of producing fewer/less random-distributed sample gaps due to the technical internals? This specifically with focus on situations when the gaze velocity would change, even substantially, but still well off a saccadic level?
2) Is it true, what I believe to have understood: the time stamp generated by the EyeX and delivered together with the gaze data is undoubtedly the raw time when the gaze data had been recorded in the device (not being submitted yet and before being evaluated by the tracker in terms of validity) and is therefore independent from any latency effects emerging further down the process line?
3) If the StreamEngine would be (substantially) better suited for providing evenly distributed samples under conditions of varying (sub saccadic) gaze velocities, would the overhead of integrating the unmanaged code into the managed code possibly outweigh that benefit by introducing latencies due to processing overhead?

I am well aware that the future implementation then would have to make use of a proper solution, which would be using the Pro series trackers, but I’m still in the PoC phase, sorting out whether the features requiring this functionality are of use for our application, and we would prefer a hands-on demonstration for this rather then a theoretical consideration.

If some of you would have answers, that would definitely help a lot,

thanks

[Simon]

Hello
My goal is to access the left and right pupil size (diameter) as it changes throughout a stream. I cannot see this through the Interaction Library.
What am I doing wrong? Where do I find this data stream?

Simon

[Grant [Tobii]]

Hi @simonsmith, the pupil size and separate eye gaze streams are advanced metrics which are only available with the Tobii Pro SDK

In order to use the Tobii Pro SDK with the 4C Tracker you must purchase a Research development license.

To obtain a quote, please get in touch with the licencing team @ https://developer.tobii.com/license-agreement/contact/

Best Wishes.

[Author]

Posts