Hi Chris,
I noticed that the signal that I’m getting from Eyelink doesn’t change when I adjust the calibration in the Eyelink system, which makes me think I’m getting the “raw” signal rather than “gaze,” which is what I want. Do you know which (if any) of the Eyelink object parameters represent calibrated gaze data? The full list of options are:
eye_rx
eye_ry
eye_lx
eye_ly
eye_x
eye_y
eye_z
href_rx
href_ry
href_lx
href_ly
pupil_rx
pupil_ry
pupil_lx
pupil_ly
pupil_size_r
pupil_size_l
Hi Evan,
As far as I can tell, MWorks isn’t getting any uncalibrated data from the EyeLink. However, you do have a choice between “gaze” (described in the EyeLink manual as “screen gaze x, y”, which “reports the actual (x, y) coordinates of the subject’s gaze on the display, compensating for distance from the display”) and “HREF” (“head referenced-calibrated x, y”, which “directly measures eye rotation angles relative to the head”). Gaze is reported via eye_rx, eye_ry, eye_lx, eye_ly; HREF goes to href_rx, href_ry, href_lx, href_ry. It seems like both sets of data should be calibrated, but it might be worth testing both.
As for the other options, eye_x, eye_y, eye_z are the 3-D gaze coordinates, as computed by the MWorks plugin using the left and right gaze data and tracking_dist. The pupil-related variables report “camera X, Y of pupil center”, which I’m guessing would not be useful to you.
Cheers,
Chris
Hi Chris,
I spoke with William Schmidt from SR Research, he says that if we want to
use the particular type of calibration that we’d like, we need to be
looking at the “raw” signal, which should be available in the link data
stream. Can we get the raw outputs included in the Eyelink object?
Thanks,
Hi Evan,
if we want to use the particular type of calibration that we’d like, we need to be looking at the “raw” signal, which should be available in the link data stream.
After further investigation, I think I was wrong: It looks like pupil_rx, pupil_ry, pupil_lx, and pupil_ly do provide the “raw” signal you want. From the EyeLink user manual:
Pupil position data is raw (x, y) coordinate pairs from the camera. It has not been converted to eye angles or to gaze position. There may be a non-linear relationship between this data and true gaze position. Pupil position is reported in integer values, with 200 to 400 units per visual degree.
When a calibration has not been performed, the EyeLink system cannot convert pupil data to the more useful data types. Raw pupil position is useful when auto-sequencing calibrations, or when the application wishes to perform its own calibration.
Does that sound like what you need? If so, it’s already available via the pupil_* outputs.
Chris
Hi Chris,
We just tried this (moved the eye position variables from eye_* to pupil_*)
and the value of the MWorks variables become static (i.e. pegged at ~2^15).
Are you sure the raw input has been implemented in MWorks?
Hi Evan,
We just tried this (moved the eye position variables from eye_* to pupil_*) and the value of the MWorks variables become static (i.e. pegged at ~2^15). Are you sure the raw input has been implemented in MWorks?
It certainly looks like it’s implemented. If the EyeLink weren’t sending pupil positions, then the pupil_* variables would be set to -32768. You’re not seeing that, which suggests the EyeLink is sending MWorks something.
I have no idea if this matters or not, but I did notice just recently that SR Research published new [drivers for OS X](SR Support Forum in July. Do you want to install those and see if it makes any difference?
If that doesn’t help, then I’ll need to try debugging with the real hardware.
Chris
Hi Evan,
As we discussed offline, the problem was that MWorks needed to tell the EyeLink (via the link_sample_data command) to include pupil coordinates in the eye data. This change will be in tonight’s nightly build.
Cheers,
Chris