UiL-OTS-labs / web-experiment-datastore

Other
0 stars 0 forks source link

Add processing module for Webgazer data #66

Open miggol opened 1 year ago

miggol commented 1 year ago

Data coming in from jsPsych's Webgazer plugin comes in a rather obtuse JSON package per trial. It would be of great assistance to researchers if it resembled more common eye-tracking data formats.

Something like this:

Item Participant PosX PosY Time
Item Participant PosX PosY Time
Item Participant PosX PosY Time
Item Participant PosX PosY Time

Of course, the datastore should always provide raw data on demand. This processed format would be a supplementary function when Webgazer data is detected. Some basic modularity to meet future processing needs is desirable.

maartenuni commented 1 year ago

You might have a look whether this is something up the sleeve of iSpector: https://github.com/UiL-OTS-labs/iSpector . I've found many difficulties of finding a "default" format for eyetracking movement. Commonly the main research grade eye tracker use/support there own stuff with their own rather expensive software. The current use of iSpector is to turn some format, into a eyelink (SR-research) ascii format, with some added metadata, so Fixation understands it, then the final analysis is done with fixation. This is at least the approach we use with Zep and the SMI eyetracker.

tymees commented 1 year ago

What's the reasoning behind making it a feature of the datastore, instead of making it a simple standalone script for example? (Or integrating the format in iSpector like Maarten suggests).

miggol commented 1 year ago

@tymees People already use the datastore, and it's the only place where this script would ever be used. So it makes sense to integrate it.

@maartenuni Thanks for mentioning iSpector, I will try to use the same output format where possible.

It might be cool to add this to iSpector as well, but once again literally the only place that this specific jspsych+webgazer json input format would ever come from is this datastore. So I would actually kind of see it as unnecessary complexity added to iSpector.