Input data: Cartesian coordinates (in pixels) or Visual Angle degrees?

[pdmadeira]

As discussed previously by email, I was wondering if the input data (x- and y- positions) has to be in pixel coordinates or if it could be in visual degrees. I've been using the algorithm and came into an interesting scenario:

• Comparing the algorithm results (default hyperparameters) when inputting data as visual degrees vs pixels, the first approach seems to more effective (see example pictures below), although the algorithm is designed to receive the values ​​in pixel coordinates

Note: My dataset is already in visual degrees (returned that way by the MonkeyLogic software), so to convert it to pixels I multiplied the x- and y- values for a converting factor 'PixelsPerDegree' (20.09), also returned by the software. I used the inverse value for the 'px2deg' conversion factor required by the REMoDNaV algorithm (1/20.09), which is very identical to the result of the calculation you suggest in the documentation.

The eye-tracking data is related to a static task.

Am I interpreting the results well when I conclude that they are more assertive for visual angles as input data? I emphasize once again that I am using hyperparameters' default values.

Thanks in advance for the help!

[adswa]

mhh, that's an interesting question. @mih, do you have thoughts on this?

[bjbraun]

I think that this comes from the fact that the speed in the algorithm is calculated via sqrt(delta_x^2 + delta_y^2). In the case where the input is the visual angle, the calculated speeds are a lot smaller because the angles are significantly smaller than the pixel coordinates. Therefore, everything is marked as fixations because the speeds are very low.

In your case it seems like it works better but I do not think that this is generally the case. You would probably achieve similar results with the px input if you increase the parameter pursuit_velthresh.

[pdmadeira]

Thanks for the answer and the effort to help, @bjbraun! I will give it a shot and return with some updates.

[pdmadeira]

[Update from the previous answer] I found 30 deg/sec a reasonable value to set the _pursuitvelthresh since it removes the great majority of misclassified smooth pursuits and remains coherent with what I found in the literature.

Meanwhile, I came with another question related to the fact that blinks keep being classified as saccades, what can I do to avoid it? This misclassification also leads to the _maxvel warning ("Computed velocity exceeds threshold") when computing the algorithm outcome.

Another problem caused by this points to the duration of the events: if a fixation is being performed and the subject blinks during it, since the blink is counted as a saccade, the total duration of the fixation is not being taken into account. Plus, two fixations are being identified instead of just one.

[bjbraun]

@pdmadeira good to hear! In which literatures did you find a value of 30 deg/sec?

Unfortunately, I do not know how to avoid the problems with blinks either.

[pdmadeira]

@bjbraun thanks for your continuous feedback! I'm still expecting someone to be able to help with the blinks issue :)

I found the 30 deg/sec choice for _pursuitvelthresh reasonable based on the articles below:

• A Review and Analysis of Eye-Gaze Estimation Systems, Algorithms and Performance Evaluation Methods in Consumer Platforms
• The upper limit of human smooth pursuit velocity
• Smooth Pursuit Eye Movement of Monkeys Naive to Laboratory Setups With Pictures and Artificial Stimuli

[bjbraun]

@pdmadeira Great, thanks a lot!

[adswa]

Closing this question-type issue, as I believe others have given informative answers. Please reopen if I am mistaken, and thanks for everyone chiming in. :)