Changes from Tobii Pro Analytics SDK 3

Since you are reading this information you have probably been working with the Tobii Pro Analytics SDK 3 and you might also be wondering about why we have made the changes we made. On this page you will find how we were thinking when we took up the challenge of making a new SDK for eye tracking with Tobii's eye trackers.

Why a new SDK?

Over the years since our first SDK was released our flora of eye trackers has grown considerably and does now also include wearable eye trackers as well as eye trackers communicating both over USB as well as regular office networks. While our older SDKs were optimized for just one type of eye tracker, i.e. a stationary network tracker, the new Tobii Pro SDK is designed to be flexible enough to handle both the eye trackers of today as well as what might be developed in the future. That said, in the first release of the Tobii Pro SDK, there is no support for our wearable eye trackers.

In addition to enabling support of other types of eye trackers, the architechture of the new SDK allows for easier support and maintenance of of current language bindings as well as expansion with new bindings in the future. While the previous SDK in practise had separate implementations for each binding, the Tobii Pro SDK builds on the same base for all bindings, but aims to tailor the interface in a way that make each binding feel like a natural part of its own framework or language, be it .NET, Python or Matlab.

Naming changes

Here you find the largest visible difference compared with previous SDKs. The aim has been to find names of classes methods, functions and parameters that would feel natural for any developer. In previous SDKs definitions primarily used by developers within Tobii were also included in the public SDK which sometimes led to confusion and inability to use the SDK to its full potiential. Hence, in the Tobii Pro SDK steps have been taken to select self explanatory names, but also to avoid including things not useful for a public audience.

The names changed are listed in the section Migrating from Tobii Pro Analytics SDK 3 for each language separately, i.e here for .NET, here for Python, here for C and here for Matlab.

Gaze validity is now validity per data type

In previous SDKs, a value between 0 to 4 was used to signify either the certainty of which eye the data was collected from or if there was any data at all in a gaze data package. In the Tobii Pro SDK all different data types, e.g. gaze point, gaze origin and pupil data, had its own validity field telling if the data is valid or not. To learn more about this, please refer to the section about Validity codes on this site.

The Tobii Pro Eye Tracker Manager

The previous SDKs were bundled with two applications called the Eye Tracker Browser and the X Configuration Tool. These applications could be used to upgrade the firmware of the eye tracker, do some diagnostics and to translate the physical setup of the eye tracker in relation to the plane where the calibration was made into something the eye tracker could handle. These two applications will now be replaced by one application, i.e. the Tobii Pro Eye Tracker Manager. In addition to the features of Eye Tracker Browser and X Configuration Tool, the Tobii Pro Eye Tracker Manager can also be used to perform calibrations on all screen based eye trackers. However, unlike the Eye Tracker Browser and X Configuration Tool, the Tobii Pro Eye Tracker Manager will not be bundled with the Tobii Pro SDK. Instead, it can be downloaded from here . Tobii Pro Eye Tracker Manager supports the Tobii Pro Spectrum, X3-120, X2-30/60, TX300, T60XL and 4C eye trackers. For other eye trackers, we recommend that you continue using the X Configuration Tool and Eye Tracker Browser.

Moving from the old SDKs to the Tobii Pro SDK

We think the Tobii Pro SDK is both easier to use and more powerful in the long run compared to the previous SDKs released by what was previously called Tobii Analysis. Hence, we do recommend you to migrate form the old SDKs to the Tobii Pro SDK. Since each binding has its own characteristics, the information about what to consider when doing a migration is written separately for each binding and found in the relevant section of this website, i.e. the .NET, Python, C or Matlab section.