The Eye Tribe

Python • Re: Data not recorded properly (PyGaze,EyeTribe)

2016-08-15T14:23:41+02:00

Based on the pictures you've posted, it seems clear, that the recording software you are using is not taking 'bad frames' into account. It seems that frames are recorded even when there is no tracking.

If this is not the functionality you are looking for, then you are free to extend the open source PyGaze repo with the needed functionality. You can also post feature requests on their GitHub page or write the author.

Statistics: Posted by skataAnders — 15 Aug 2016, 14:23

Python • Un-official Python SDKs

2016-08-15T12:46:08+02:00

The Eye Tribe do not have an official Python SDK implementation. Instead, the community has provided implementations of the open EyeTribe API. Find these (in random order) below:

https://github.com/esdalmaijer/PyTribe

https://github.com/sjobeek/pytribe

https://github.com/baekgaard/peyetribe

https://github.com/djsmedes/thepyetribe

Statistics: Posted by skataAnders — 15 Aug 2016, 12:46

Python • Data not recorded properly (PyGaze,EyeTribe)

2016-04-20T11:25:02+02:00

Hi everyone,

I made an experiment where one has to read a small text in OpenSesame, using PyGaze to record eye movement from the EyeTribe.
The problem is: I have a huge loss of data in the resulting .tsv file, as if the eyes were closed (lines of zeroes). Also, if the EyeTribe samplerate is set to 60Hz, the data of almost half the text are not recorded. At 30Hz, this last problem doesn't seem to occur though.

I thought it might be an issue with OpenSesame, so I made a script directly in Python using PyGaze. I still have the same problem...
If it can help, I made sure that the average calibration error was always smaller than 1, I used multiple computers (but only one EyeTribe).

Some images of the scanpaths created with the resulting .tsv:

At 30Hz with PyGaze:

And the associated .tsv: https://drive.google.com/open?id=0BzDY9INkgoAWN1NEa09vQmo3Tmc

At 60Hz with OpenSesame:

And the asociated .tsv: https://drive.google.com/open?id=0BzDY9INkgoAWbWtZZW9vS1NpeGs

At 30Hz with OpenSesame:

And the associated .tsv: https://drive.google.com/open?id=0BzDY9INkgoAWbEIxcWZkRXBBSTQ

Cheers,

Statistics: Posted by skatafabien.malassingne@gmail.com — 20 Apr 2016, 11:25

Python • Re: How do I get the 3D head coordinates in Python through t

2015-02-11T10:05:03+02:00

You should look at fetching pupil coordinates from the frame object as documented by the API

Statistics: Posted by skataAnders — 11 Feb 2015, 10:05

Python • How do I get the 3D head coordinates in Python through the A

2015-01-20T16:32:57+02:00

I am working with custom software, and I'm attempting to make a "show eyes" function before calibration where you can see if the tracker is picking up on your eyes, and then position yourself correctly with regards to the appropriate distance away from the tracker. This is similar to what the eye tribe UI does, so I'm assuming it can be done? Do you know of an easy way to get these 3D position coordinates (not gaze, but position of the head with regards to the tracker) in Python through the API?

Statistics: Posted by skatabdohert — 20 Jan 2015, 16:32

Python • Updated peyetribe

2014-08-14T16:42:09+02:00

There now seems to be an abundance of python interfaces to the eye tribe

I have nevertheless updated the peyetribe interface a bit, to make it more robust and maybe also easier to use.

It works with both python3 and python2, so you could use it with e.g. the PsychoPy toolbox and others that are not updated to python3 yet. Just copy the peyetribe.py file to the directory where you have your other python files (or install it as a module).

It offers a very simple interface, and hides most of the complexity of multiple threads (listener and heartbeat).

A very simple use case could be as follows, using the tracker in pull mode:

Code:: from peyetribe import eyetribe tracker = eyetribe() tracker.connect() while True: # or some better condition... n = tracker.next() print(str(n)) tracker.close()

Or a more elaborate example, using push mode and relying on multiple synchronised threads and internal queues that ensure you don't loose any data, and only printing the left eye coordinates:

Code:: from peyetribe import eyetribe tracker = eyetribe(host="your.host", port=1234) tracker.connect() tracker.pushmode() count = 0 while count < 100: n = tracker.next() print("Left: %s" % (str(n.geteye(left=True)))) count += 1 tracker.pullmode() tracker.close()

It can still be found at https://github.com/baekgaard/peyetribe

I may still clean up the code a bit; this has evolved some over time and could obviously be made smarter in some places.

Comments or ideas for improvement are obviously welcome

Statistics: Posted by skatapgba@dtu.dk — 14 Aug 2014, 16:42

Python • Re: My take on a Python module

2014-08-13T16:04:55+02:00

Enjoy

Statistics: Posted by skataMSchulte — 13 Aug 2014, 16:04

Python • Re: Python wrapper

2014-08-12T01:56:40+02:00

Thanks for the very good input on the response handling! I've used the tips in the newest version of my wrapper (can be found here: https://github.com/esdalmaijer/PyTribe), which is now integrated in PyGaze (https://github.com/esdalmaijer/PyGaze, see for the specific module: https://github.com/esdalmaijer/PyGaze/blob/master/pygaze/_eyetracker/libeyetribe.py).

Cheers!
Edwin

Statistics: Posted by skataesdalmaijer — 12 Aug 2014, 01:56

Python • Re: My take on a Python module

2014-08-12T01:52:44+02:00

Looks very good! In return, I'm borrowing that queued responses idea of yours

Statistics: Posted by skataesdalmaijer — 12 Aug 2014, 01:52

Python • Re: My take on a Python module

2014-08-08T16:18:25+02:00

Just realized that my code has a sneaky bug in it. Line 211 reads:

Code:: self._frame_file.write('{}\n'.format(msg))

But it should be:

Code:: self._frame_file.write('{}\n'.format(raw_msg))

By recording msg instead of raw_msg to the file, I accidentally made it write a representation of a Python dict, rather than the JSON-formatted string given by the tracker. I will commit a fix in a few hours.

I discovered this after trying to parse a bunch of data (that we paid subjects to collect!) and getting repeated JSON errors. I got around it by simply using eval() instead of json.loads() on the saved data.

Cheers,
Daniel

Statistics: Posted by skataMSchulte — 08 Aug 2014, 16:18

Python • My take on a Python module

2014-08-07T11:57:12+02:00

https://github.com/djsmedes/thepyetribe

I've been working with these trackers for the better part of three months, and after a few different iterations, this is the best way I have come up with for communicating with it.

It uses new-style classes, i.e. inheriting from object, and Python's @property and @property.setter decorators to simplify access to the tracker's attributes.

It uses a HeartThread to send heartbeats. I specifically don't give the thread access to the socket, but instead pass in an anonymous lambda function that, when called, sends the heartbeat. Not terribly important in this case, but I think in general it's a good idea to compartmentalize, if only so that you are not tempted to write more complex and dangerous code.

It uses a ListenerThread to constantly receive data from the socket and put it into a Queue. We split on newlines so that each message the tracker sends is its own item in the Queue, even if they are sent so close together that they pop out of the same socket.recv call. This thread is also passed an anonymous lambda function, lambda: self.socket.recv(BUFSIZE), for reasons similar to the above.

It uses a ProcessorThread to take strings from the raw Queue, parse them into dicts, and put them into an appropriate "EyeTribeQueue" or write them to a file. The parsing is achieved in two stages: first, a string.replace call which turns the C error "-1.#IND" into "null" because Python's json module does not know what to do with that C error. If more things like this are observed, more processing will be done in this stage. The second stage is to call json.loads on the string. We then check a few keys in the dict for certain conditions, which determines whether we write the message to a file, put it in one of the EyeTribeQueues, or notify that certain conditions have changed (i.e. display index). Note that when in push mode, frame data will still have a request of "get," which I am not sure is accurately reflected on the documentation on this website. If that were to change, some changes would need to be made to the logic in this thread.

The EyeTribeQueue inherits from LifoQueue, but replaces the normal Queue.get() method with an error message. Instead, you use the new Queue.get_item(request [, values]) method, which will go through the Queue's underlying data structure (a list in this case, which is why we inherited from LifoQueue instead of just Queue) and pull out the message that has the specified request (and values if the request was "get").

There is only one place in the code where socket.send() is called, but multiple threads could conceivably all be trying to do this simultaneously, so we include a threading.Lock object there.

I would like to thank Edwin Dalmaijer for sharing his code at https://github.com/esdalmaijer/PyTribe. I got the idea of storing the most recent frame as a "current frame" object from him, and probably a lot of other things were inspired by his code as well.

Comments, questions, and critiques welcome!

Cheers,
Daniel Smedema

(MSchulte is not actually me, it's my boss, but he's the one with the account here)

Statistics: Posted by skataMSchulte — 07 Aug 2014, 11:57

Python • Re: Python wrapper

2014-08-05T10:46:50+02:00

I actually changed the way I was doing things to make use of python's new-style classes and property decorators, which turned out to be quite handy. I also implemented a different way of dealing with command-reply matching: a custom Queue object. It inherits from Queue.LifoQueue, overrides the get() method to return an error, and adds a get_item() method that searches through the Queue and returns an item matching your request (and values if you pass those in as an argument, to distinguish between multiple request: get and request: set commands).

I'm not sure that I really NEED the lock anymore because of the changes I have made. I only have one thread ever recv-ing from the socket, but multiple functions that could send. It depends on if socket.send is inherently thread-safe, and I'm not prepared to assume that, so I am leaving in the lock for now.

I'll post my whole wrapper some time before next Wednesday .

Cheers,
Daniel Smedema

p.s. MSchulte is actually my boss, if anyone is curious why my name and username are so different.

Statistics: Posted by skataMSchulte — 05 Aug 2014, 10:46

Python • Re: Python wrapper

2014-07-28T21:16:30+02:00

That's a very good question, and your solution seems more elegant. It's pretty much the result of building on a proof-of-principle script; there was no real design choice behind it.

On the Lock: this is something that I still need to implement, but purely due to the hypothetical possibility of receiving the wrong kind of response. I haven't actually had problems with this yet, presumably due to a lower heartbeat frequency.

Thanks for the suggestions!

EDIT (30-Jul-2014): added the suggested Threading Lock yesterday. Immediately noticed the need for one, as it started raining replies to different commands (currently working on a command-reply matching strategy). Thanks again!

Statistics: Posted by skataesdalmaijer — 28 Jul 2014, 21:16

Python • Re: Python wrapper

2014-07-04T14:11:36+02:00

Looks quite nice!

I've been working on something similar, though I have been focusing more on getting the specific things I need for my project working and not on creating a complete wrapper like you have. I did things a bit differently--I created classes HeartThread and ListenerThread, for example, instead of functions that need to be called as the target of a thread.

I've been sort of hacking this code together with no regard for style guidelines, but in the next few weeks I intend to clean it up and post it here.

In the mean time, I'm curious--why don't you use the json.dumps function in your connection.create_json method? I have this function, for example:

Code:: def send_message(self, category, request=None, values=None): '''returns the reply in a dict''' to_send = {} to_send[u'category'] = category if request is not None: to_send[u'request'] = request if values is not None: to_send[u'values'] = values to_send = json.dumps(to_send) with self.lock: self.socket.send(to_send) reply = self.socket.recv(BUFSIZE) return json.loads(reply)

I'm also using a threading.Lock() object, which is self.lock in the code above, for thread safety. I kept receiving heartbeat replies when I was trying to retrieve frame data before I added that. here's my HeartThread class (excuse the lack of documentation--will add it soon):

Code:: class HeartThread(threading.Thread): def __init__(self, et_socket, socket_lock): super(HeartThread, self).__init__() self._stop = threading.Event() self.socket = et_socket self.lock = socket_lock def stop(self): self._stop.set() def run(self, interval=0.250): while not self._stop.is_set(): with self.lock: self.socket.send('{"category":"heartbeat"}') logging.debug('Heartbeat reply: {}'.format(self.socket.recv(BUFSIZE))) sleep(interval) # example call heart_thr = HeartThread(self.socket, self.lock) heart_thr.run()

Statistics: Posted by skataMSchulte — 04 Jul 2014, 14:11

Python • Python wrapper

2014-07-01T02:33:44+02:00

Hi guys,

https://github.com/esdalmaijer/PyTribe is a first attempt at creating a decent Python wrapper. The current classes are for simple communication with the eye tracker by using methods, which saves you from continuously having to send and parse JSON messages.

I plan to write an EyeTribe class on top of this soon, with higher level methods (e.g. 'calibrate', 'validate', 'drift_check', 'start_recording', 'stop_recording' etc., much like these: https://github.com/esdalmaijer/PyGaze/t ... eyetracker). But please do have a go at testing the current classes; any feedback is welcome!

Best,
Edwin

Statistics: Posted by skataesdalmaijer — 01 Jul 2014, 02:33