Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

EyeLink calibration wierdness #368

Open
drammock opened this issue Apr 8, 2019 · 8 comments
Open

EyeLink calibration wierdness #368

drammock opened this issue Apr 8, 2019 · 8 comments

Comments

@drammock
Copy link
Member

drammock commented Apr 8, 2019

I'm setting up expyfun + EyeLink in Matt's lab, and we're hitting something really strange. When running the EyeLink calibration through expyfun, three unexpected things happen:

  1. during both calibration and validation, the calibration dot locations are flipped up-down relative to what shows on the EyeLink monitor
  2. during validation, only 4 of the 5 points are being tested; on the subject's screen the bottom point is omitted; on the EyeLink monitor the top point is omitted.
  3. as a result of (2), when expyfun calls pyeparse to parse the EDF (e.g., in the pupil dynamic range codeblock), it fails with an IndexError because it expects 5 calibration/validation lines in the EDF ASCII file, and finds only 4.

At first I thought possibly related to #318? Only I undid the code change from #318 locally and it doesn't seem to have changed anything.

@larsoner @maddycapp27 @rkmaddox does any of this sound familiar? Any ideas? I'm (foolishly?) hoping it's something you've seen and fixed locally and forgot to push up to the codebase.

@larsoner
Copy link
Member

larsoner commented Apr 9, 2019

during both calibration and validation, the calibration dot locations are flipped up-down relative to what shows on the EyeLink monitor

No ideas. I'm not sure that we've ever done vertical analysis beyond "how much vertical deviation was there" so I suppose it's possible that this has always been broken. Sounds like the definitions of "+Y" in the Eyelink/PyLink and expyfun are reversed. I'd try reversing them to see if it fixes things. Then we'll need to test at another site -- hopefully @maddycapp27 can try because I don't have easy access to an EyeLink right now.

during validation, only 4 of the 5 points are being tested; on the subject's screen the bottom point is omitted; on the EyeLink monitor the top point is omitted.

This I have never seen. We wouldn't have been able to do experiments before if this were the case. So it seems like perhaps something has changed -- a PyLink library update? I wonder if that beta version for 3.4+ has some new, possibly buggy code.

I would try quickly setting up a Python 2.7 environment with the old/stable PyLink library to rule that possibility out.

@drammock
Copy link
Member Author

drammock commented Apr 9, 2019 via email

@drammock
Copy link
Member Author

Update: Running pupillometry example test script in a py2.7 environment has the same problem: calibration points are flipped up/down between what shows on display screen and what shows on eyetracker monitor, and during validation the last point is skipped (causing pyeparse to choke after the dynamic range block, when it tries to parse the validation points and finds one too few lines, yielding list index out of range).

@drammock
Copy link
Member Author

The pyeparse problem can be hacked around by changing here the two cases of .format(nsamples) to .format(nsamples + 1)

@larsoner
Copy link
Member

That's really weird. I don't know why this would be needed. Maybe there is some EyeLink software difference between the UW/UR systems and the UM one.

@drammock
Copy link
Member Author

I wondered about that, but Matt's psychtoolbox-based calibration setup doesn't have this vertical-flip weirdness.

@larsoner
Copy link
Member

The vertical flip could be a bug that has always been there. I'm talking about the number of samples business.

@drammock
Copy link
Member Author

update: I tried locally changing on this line v_pix to -1 * v_pix in an attempt to fix the up/down mismatch between what display shows and what EL monitor shows. Perhaps predictably, it didn't fix it (rather it just effectively switched the order of whether top or bottom dot came first in the calibration sequence --- but the mismatch persisted).

Also, @mwinn83 thinks that the EL interface does screen coords with origin at top left (he vaguely recalls this from when he and Alan developed MATLAB exps that used EyeLink).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants