Hi 👋 I’m looking to use eye tracking on Linux to control the desktop mouse cursor position, with mouse clicks triggered via keyboard keybinds (no dwell clicking). Eye tracking would be used only for pointing, not clicking.

I’m considering Pupil Labs hardware/software and wanted to ask: is Pupil Labs a good fit for this kind of gaze-to-cursor control use case?

I’m particularly interested in how difficult it is to integrate Pupil Labs on Linux as a system mouse input (i.e. mapping real-time gaze data to cursor movement with filtering/smoothing).

Thanks in advance!

Hi!

I’m using Pupil Core with 3D gaze mapping (binocular, gaze.3d.01). Even when fixating ~2m away, gaze_point_3d.z seems to saturate around ~600–800mm. Also, it doesn't look stable. I’ve tried Screen Marker and Single Marker, but the depth behavior didn’t change much.

Is this expected due to binocular disparity limits at far distances? Is application-side depth calibration (e.g. mapping observed z to real distance using multiple known depths like 0.5m / 1m / 2m) the recommended approach, or are there other calibration methods that could improve depth accuracy?

Thanks!

hi. I have some difficulties using a mouse, so I would like to use your project to control the cursor using a smartphone camera. Is this possible? Or it works with your devices only? Sorry for my English.

yes, move, click, drag etc

I want to use on my pc (WINDOWS)

by the way link from DIY is broken https://i.materialise.com/en/shop/designer/pupil-labs it redirected to main page. ty for support. i will check it all

Hi @user-f43a29, @user-cdcab0 . We are having trouble getting good calibration. Sometimes, with new participants not familiar with eye tracking, it takes almost an hour for them to get the hang of calibration. Spending too much time on calibration makes it difficult to get enough trials of data of actual experiment. We cannot compromise on the calibration as the protocol is gaze contigent and the trials don't proceed unless participant's eyes stays on the cues for 1000 to 1440 ms of jittered fixation ( and this can happen only if the calibration is good and head absolutely does not move during the trial) Issues with calibration: 1. During calibration if they blink we get eye position to be slightly rotated around the horizontal axis, although the participant is clearly looking at the cursor we are showing 2. If they anticipate, we get eye position almost 45 degree rotated from where they are looking ( for example a cursor). These two we explicitly instruct and retry again and again. But so many repetitions tire the participant and their eyes evenbefore we start the task. 3. Recently we had participants whose eyes water. So we end up not being able to calibrate at all. I would like to share with you two latest recording in which participants eyes were watery, but we felt the eye image and the calibration accuracy was good. However when we do a cursor follow check, the pink point showing realtime eye position is really off ( a video of cursor check for 2 instances of calibration is markerd 'Recording 2026-01-14_001' and 'Recording 2026-01-14_002' and shared along with the pupil recordings. Please have a look and let us know how we can make calibration process easier and faster for the participants, allowing us to save on the experiment time. https://1drv.ms/f/c/FB1DFB83EAA92E53/IgCO24RcIKEqTatx-TMhcYw4AaWyKY7SxyvTSI550iKsnlM?e=UkhBvW

Hi, I'm currently working on research conducted using the Pupil Core glasses with my professor. After the files were collected and cleaned up, I realized all the recorded sessions only have data for the right eye. I double checked multiple files by running a code to check for Eye ID for the left eye (so ID=1). has this occurred with anyone else? i'm unsure if the issue is with the recording device because I have the video recording of the left eye.

Hi @user-3bcb3f. Thanks for your message. I have reviewed the recordings you shared.

To start, the eye cameras are excellently positioned and pupil detection is very robust. Furthermore, the overall accuracy appears exceptional, particularly in areas close to the calibration points. I do not believe it is possible to obtain better accuracy in these regions; it looks to be approximately <0.8 degrees.

Accuracy does reduce in regions of the screen where there were no calibration points. This is expected, as the 2D calibration pipeline does not extrapolate well outside of the calibration areas.

I see you are using the nine-point calibration choreography plugin. I strongly recommend adding two to four additional points in the regions where you are seeing reduced accuracy. You can add them in manually to the file in the plugins folder. I expect this will improve those areas significantly and bring them in line with the rest of the display.

Finally, calibrating for one hour is well beyond what should be expected. The sequence should take no more than 10 seconds to complete, assuming everything is set up appropriately. The participant simply sits with their head still and follows the gaze target. Is there an element of your setup causing this process to drag out? Any further information would be very helpful.

You can modify the plugin by adding new coordinates, e.g. in a text editor, and saving the file - https://gist.github.com/papr/339dcb08caef45d3798a68aa4e619269#file-nine_point_calibration-py-L14 Once a given calibration point has been gazed, it should disappear and reappear very quickly in a new location. As I said, usually in less than 10 s for the whole sequence. If the subject blinks in-between, it's not a problem. If they blink a lot whilst gazing at the calibration target, then that will obviously be detrimental to the overall accuracy.

Hi @user-3bcb3f! No problem at all. Please find my responses below: 1. Any calibration choreography depends on the participant being able to gaze at the targets. As long as they do this for the majority of the samples, outlying gaze points (from anticipation, for example) should not impact the overall accuracy. The errors you are seeing in those specific portions of the screen, where no calibration targets were presented, would likely disappear once the nine-point calibration is modified to include additional points in those locations. 2. The default setting offers a good balance between duration and accuracy. 3. To be clear, the results you see at the central point in the video already demonstrate very good accuracy. You cannot reasonably expect more accuracy from the Core system. If your research requires greater accuracy than this, you would need to work with a desk-mounted system, such as an EyeLink. But with that said, you mention that the subjects' gaze must stay focused on the cues for 1000 to 1440 ms before a trial - how big exactly is the cue, in terms of degrees of visual angle?

Hello, sorry, could I check if the gaze_point_3d is the camera space and if I need to find it in the 3d world, I would need to convert from camera to world coordinate system?

Hi @user-4c21e5 1. We did the modified calibration, and yes, we were able to reduce the errors on specific portions of the screen due to anticipation by adding a calibration point there. 3. The central point is 1 degree visual angle, but there is a 2 degree visual angle window around it, not visible to the participant, in which we assume that they got their fixation right.

Hi, I just started working with Eye-Tracking and the pupil labs core glasses were provided to us by another research group. Unfortunately the cables between the eye-cam and the USB-C cable got disconnected (see attached picture). Does anybody know what is the correct order to connect them again or maybe has any useful tips for that? I couldn't find anything in the Docs and the only info I found here was, that the connectors are a JST type SH (1.0 mm) and sometimes tricky to be replaced. Thank you in advance!

Hi @user-c62860 , the team says that will need to be returned for recabling. If you have the original Order ID, then please send that to info@pupil-labs.com with an email describing the issue. Then, a member of the Operations team will reach out with instructions.

Hello! I recorded 18 sessions of aprox 50 minutes duration with Pupil Core. I am now trying to obtain the pupil diameter data through Pupil Player export. However, when dropping one session folder onto Pupil Player, the software freezes on message: "Updating recording format. This may take a while!". Is there any other way I could obtain the pupil data csv? From the raw recorded files I have pupil pldata and npy files. Thank you in advance!

It has been frozen like this for 15 minutes. But doesn't crash with error.

Okay thanks! Isn't there any other way I could export the data from de pldata and npy files? Thinking about how long it would take to do this process for 18 seessions

Understood. Thank you for replying so fast!

Good afternoon! I am experiencing a problem that I have seen vaguely addressed in some of the docs but wanted to confirm what I think is the problem.

I have a pupil core headset that is experiencing some problems that I believe may be hardware related. What is happening is that I am getting errors where the camera is randomly disconnecting and then I get TurboJPEG errors and then normally what happens is that Pupil Capture will then force close.

I have tried testing on 5 different laptops with at least one MacOS and Windows OS plus several different USB cables, with adapters, without adapters, and the issue persists. I am assuming that the issue is related to the hardware or the pigtail usb connecter that connects to the headset frame.

Please let me know and thanks for the help!

Hi @user-5f9f8f , this sounds like a hardware issue. Is it one of the eye cameras that is disconnecting or the world camera?

Can you try restarting Pupil Capture with default settings? The button is found in the General Settings tab.