Restating Ko’s problem for the archive: In his experiment, he calibrates the eye signal using the begin_calibration_average and end_calibration_average_and_take_sample actions. The calibration appears to work correctly. However, in MWClient’s eye window, the red cross that displays to indicate the eye location of an accepted calibration sample is noticeably displaced from the location of the fixation window.
Hi Ko,
As currently implemented, the location of the red cross in the eye window is the averaged value of the uncalibrated eye coordinates (eye_h_raw, eye_v_raw in your experiment) during the fixation period. However, the input to the fixation point stimulus, which is used to determine whether the subject’s gaze lies within the fixation window, is calibrated eye coordinates (eye_h, eye_v). Hence, unless the uncalibrated coordinates are already pretty close to the desired post-calibration targets, there’s no reason to expect the red cross and the green fixation window to be aligned. In fact, if your uncalibrated eye coordinates are “raw” position data from the EyeLink 1000, then the red cross generally won’t be visible at all, since the numerical domain of the uncalibrated data extends far beyond the bounds of the display in visual angle.
Since your experiment uses the analog output from the EyeLink, the input domain (-10V to 10V) does lie within the display bounds, so the red cross is always visible. However, there’s still no reason to expect its position to match closely that of the fixation window.
Thinking about it now, this strikes me as a strange design choice for the eye window. Every calibration sample notification it receives contains both the uncalibrated coordinates and the result of feeding those coordinates through the current calibration. It seems like the eye window really should use the latter coordinates when drawing the red cross, since, as noted previously, the uncalibrated coordinates could come from a wildly different domain. What do you think? If I made this change, would you be willing to test it?
Chris
Hi Chris,
Sure. Please implement this. I will try it. This might also explain why I was having so much trouble with the digital signal.
Thanks,
Ko
Hi Ko,
Thinking about it now, this strikes me as a strange design choice for the eye window.
As we discussed offline, I think this is actually a bug in the eye window’s implementation, which was masked for a long time by another bug that I fixed about a year ago.
Sure. Please implement this. I will try it.
I’ve made the change and generated a new MWorks build for you to try. You can download the installer at
http://dicarlo-mwdev.mit.edu/mw/MWorks-eye_window_fix.dmg
When you’re finished testing, I recommend that you revert to your previous MWorks installation before continuing with data collection. For details on how to do this, see Uninstalling MWorks.
Cheers,
Chris
Hi Ko,
Have you had a chance to test the updated eye window yet?
Thanks,
Chris