Upgrades and new functionality to be added in near future

[kheki4]

Dear Mr. Babak Zandi and fellow researchers,

We have bought a proper camera, and set up for experiments in the lab. However, we needed other functionality that is not currently supported in PupilEXT. So I downloaded the code, set up the build environment and everything a few weeks ago, and added the functionality myself /partially working on it right now. It came to my mind that it would be fair to contribute to the whole project by uploading my code to the github repository. I would like to hear your opinion, so I open this thread right here.

The already added functionality:

1, Arguments can be passed when PupilEXT.exe is called from command line, with specific purpose to allow the app to connect to a specified camera, to warm it up. (We plan to use scheduled wake-on-lan messages to the computer to wake it up an hour before an experimental session starts, in order to maximize recording stability. Using simple Windows startup scheduled run, only an .exe or .bat or similar file could be executed after starting up.) So an argument is added, which allows the user to specify the friendly name of the camera, and if the Pylon device enumeration code finds it, it will immediately connect to it after the program started. Also other arguments can be added easily from now on.

2, Allow PupilEXT to be remotely controlled by UDP messages (send and receive UDP datagrams, also from localhost if needed). This serves several purposes:

• To trace "trial numbers" associated with recorded samples. Trial numbering can be incremented by a specific UDP message, just like SMI, EyeLink, and other eye trackers allow this. (In line with this, one additional column is added to the output csv file, to store trial numbers.)
• To allow remote control of the app, like connection to a camera, starting pupil tracking, changing algorithms, specifying current csv or images output paths, start csv logging, stop them, etc.
• To to possibly use the app for neurofeedback and interactive paradigm studies, where the experimental code (run in Matlab or whatever, not necessarily python) should be receiving live pupil size data. This data could be sent by UDP. Also a "local server" mode is possible if the host machine is the same as the experimental machine (using localhost UDP messages).

3, Allow PupilEXT to use any camera that is recognized as a camera in opencv (like webcam) mostly for development purposes. When I take my developer computer home, or out of the lab, I do not want to unscrew and move the whole Basler camera setup if not necessary, so this functionality is useful. Also I guess other people would like to experiment with low-grade cameras: like those without global shutter, or that have low resolution and temporal fidelity. For really simple baseline pupil size change tracking, those could be also useable I think.

4, Allow option to change csv delimiter character.

Things that I plan to add in near future:

5, Allow not only "trial numbering" increment trigger command, but custom triggers, that could be traced back when the csv is opened for processing. It is useful, for example when inside a trial there are smaller temporal sections to be handled differently later, like how EEG recordings usually contain certain trigger events associated with specific "trigger codes".

6, PupilEXT to have the same commands and send/receive functionality as UDP, but by serial communication, using a "null modem" cable connection to another computer.

7, Allow changing Basler camera image acquisition settings, like binning, decimation, shutter mode at least from app starting arguments, or UDP/serial commands too. This could be used to study the effect of lower acquisition quality on detected size and artifacts.

In the long-run:

8, Reorganize code to use a wrapper class for all Basler functions, and allow adding other brands industrial camera APIs using a compatible wrapper if someone writes it. EDIT: I wrote this by mistake. It is because I wrote the webcam code in february and since then the code was in my "drawer", and when I thought about possibilities now, I forgot that e.g. "SingleCamera" class is already a "wrapper" class itself. Apart from this, maybe code could be reformed a little bit, but that's not important right here.

9, Integrate blink detection, and log "blink" events into the same or an additional csv file.

My questions:

A, What should be the "compatibility policy" regarding csv output?

• For trial numbering, a simple column can be added, containing unsigned integer values. Should this (and probably later all other) new column(s) be added after all already existing columns? (So at the very end of the header?)
• In hope for later implementation of blink detection, and also for storing trigger events separately, it could be useful to designate a new csv file for this purpose. This could be created and appended to, on demand /while the recording is going on, just like the current csv containing the samples is handled. It could contain trigger events (and later: blinks). Personally I do not like multiheader files, so I would not recommend to store these events as different length and type lines interrupting the already existing csv file (e.g. Matlab cannot read those files nicely), and I suggest this "events csv" should also be maintained a single header fashion.

B, Can/should I just upload the code in the repository once it is all tested and ready? (I have never made a commit ever before in my life. I am a hobby programmer in the last 6 years, and I have not yet contributed on Git before.)

I appreciate any suggestions, tips, and helpful opinion.

Greetings

[BZandi]

Thank you for your work and contributing to the PupilEXT project. I think you need to highlight the code snippets that you have added, allowing to better follow the updates in the future. For example, you could make comments above the updated code, like

% -------------------------------------
% Author: Your Name
% Date: The date of change
% Updated: Info text what was changed

........Here is your code.....

% -------------------------------------

You can clone this project into your repository and make the changes in your own GitHub repo. Later on, if everything works fine, we can merge the code together. It is better to carefully watch a comprehensive GitHub tutorial on YouTube before we carry on. Please let me know how it goes.

[kheki4]

Thank you! I will write in a month or so, when I proceed with the planned things.

[kheki4]

Several points I mentioned are now ready to get the last bugfixes and try in action. But it came to my mind, that the program could also have its camera-image handling functionalities extended. Given the already written code, it would be easy to change all related classes.
As of today, OpenPupilEXT v0.1.1 beta supports the following:

1. use 1 camera for detection of 1 pupil,
2. use 2 cameras for stereoscopic detection of 1 pupil

Briefly, my suggestion is that, other pupil detection configurations could be added to be used in different physical camera configurations too, like these:
3. use 1 camera for detection of 2 pupils at once (like one of our eye trackers at my university, an SMI HiSpeed 1250 does, by directly looking at both eyes through a dichroic mirror)
4. use 2 cameras for stereoscopic detection of 2 pupils at once (even though computationally heavy)
5. use 1 "mirrored" camera for stereoscopic detection of 1 pupil, by help of two pair of simple mirrors (cheap but effective, if the camera has good enough resolution)

I think these could be useful for later adding the capability for basic gaze tracking too, which is sometimes also used in combination with pupil data for certain pupillometry paradigms.

For easier understanding, I made little pictograms of the existing configurations and the new ones I propose:

These changes would need some additional code for e.g. handling different cases of pupil detection, handling multiple ROIs for finding pupils, etc... and I propose that several existing methods and variables should be refactored to provide a more understandable code for other contributors in the future. My suggestion for the naming I would be using:
1, ...Image ==> ...SingleImageForOnePupil (to be refactored)
2, ...StereoImage ==>...StereoImageForOnePupil (to be refactored)
3, ...SingleImageForTwoPupil (new)
4, ...StereoImageForTwoPupil
5, ...MirrImageForOnePupil (new)

Please let me know, what do you think about these ideas? @BZandi

[BZandi]

When adding new options for tracking the pupil, e.g. two eyes with one camera, it is necessary to include a panel in the GUI where you can configure or activate specific options. Currently, such options (ROI selection, for example) can be activated in the pupil detection window of PupilEXT. I think this is the right place to include new "beta" options. In this way the base functions remain steady, but new features can be activated.

Two eyes could be recognized when using two ROI selections, one for the right eye and another for the left eye. This feature can be added as checkbox in the pupil detection window. Then, a if condition can be added in the methods. A more elegant approach would be to use a Yolo network (or similar) to track the eyes' ROIs in the image automatically. However, with these new options, you will suffer performance, limiting your maximum fps.

[kheki4]

Thank you! I like this idea, and I will try to make it the way you said, and tell when I proceed.

Automatically finding the eyes also came to my mind. I actually only have a 35mm lens, which does not allow for moving the head around too much, also focus can be lost easily... but I guess with other lens, continous tracking of eyes could be possible optically.
I think not every frame should be used for finding the eye positions, because as you pointed out, that would cost processing power, but maybe only one frame per e.g. every half second could be a reasonable sacrifice. Also, I think first we could just fast check that whether some easily computable feature of the image (e.g. mean of pixels in each row or each column) differs significantly from the same metric computed from the image one half second before when ROI was set the last time... and if it does, we can conclude that possibly the head has moved, and we need to reposition or resize the pupil detection ROI. This is an interesting problem, and I will be thinking about this.

[kheki4]

@BZandi I am just informing you and passers-by that the work is going fine, but I recently have personal things going on. I expect the codes be ready (in the beginning of january. edit on 2023.01.06.:) around the end of january. I will post here when things proceed. Thanks

[kheki4]

I could just sit back to the computer today. I changed a little bit on the code now: there was a little bug and a few missing lines in the trial increment reader code (recEventTracker), and one in the image playback control dialog code (caused stuck disabled buttons). Also I have to say that my "rational and discrete" pupil detection ROI changer codes are buggy yet, I will get back to it in near future. Also I will write together the list I mentioned in my last comment, in a day or so. Greetings

[kheki4]

Here is the list I talked about :) Please excuse me for being late with it:

---

Done:

• Important: timestamps of CameraImage objects leaving imageReader class are now consistent with the time of image acquisition, not the time of image reading operation. I think this is clearer (as in case of a real camera, the timestamp variable contains the acquisition timestamp). However, this also necessitates that all image files must have the correct/corresponding timestamp numbers in their names (see code). But this modification makes the "filename" string filed unnecessary. I left it there yet.
• Fixed the bug that caused crash when path depth was too short for image output directory, the program crashed.
• Added feature to automatically, iteratively create subfolders if the specified image recording or CSV output path does not exist (relevant when these paths are specified via remote control commands instead of folder selector dialog in GUI).
• Delimiter symbol can be changed, and this setting will affect any CSV files generated by the program.
• It is possible to remotely control the application through UDP messages or commands over serial(COM) port. Accordingly, serial ports are not only used by SerialSettingsDialog anymore. To handle the consequences optimally, now there is a serial port pool (a class that manages a vector of SerialPort instances), that are passed to different class instances that need serial to work with. "Remote Control Conn." red/green indicator dot is added to the main window status bar. A dialog for "Remote Control Connection" is added to "Settings" menu of main window.
• It is possible to stream ongoing pupil detection output to a target UDP connection or COM port. This connection can be the same that is already used (already listening) for remote control. It is possible to stream to both UDP or COM connections, although not efficient to do so. Localhost can be used too. Pupil Detection output can be serialized in different formats: CSV row (using the delimiter set globally), JSON, XML and YAML. This widens the application of PupilEXT to uses in e.g. neurofeedback, interactive paradigms and brain-computer interface research.
• A class called MetaSnapshotOrganizer can now save all the important information regarding the image acquisition and pupil detection, upon certain events, e.g. a new image recording is started, or a pupil detection CSV recording is begun. This is written to an XML file in the regarding output folder, and contains settings that may need to be reproduced later for coherent data acquisition along multiple subjects, even is settings are not logged but changed by someone meanwhile. Pupil detection algorithm settings are not yet implemented to be saved (however this would be an important to-do).
• "Serial Connection" settings menu item, and dialog was renamed to "Camera Serial Conn." as serial connection is now in also use in other contexts within the GUI. Serial Connection red/green indicator dot in main window status bar is renamed to "Camera Serial Conn."
• Added capability to change image acquisition ROI size (internal, camera setting) and location, as well as binning level, through camera settings dialogs.
• Added a camera temperature checker class, running in a thread. Checks physical camera device coreboard temperature every 5 seconds. (Still lacks a checkbox and spinbox settings in general settings dialog.)
• "Open Images Directory" option is now disabled while there is already an image directory opened for playback.
• Added capability for ImageReader class to not read unimportant files in an images directory. When imageReader is created, it checks the directory contents, and if finds any file that is not of the most common extension locally, it rejects that/those from reading later on.
• In case of fileCamera, in camera view dialogs, the "Camera FPS:" label is changed now to "Image read FPS:"
• Added imagePlaybackControlDialog, where playback control can be managed. It takes care of lagged images that naturally occur due to the pupil detection processing thread, when tracking is on. Also when looping is set to off, it stops playback with taking care of image lag. Playback loop checkbox and Playback FPS value settings moved to playbackControlDialog from generalSettingsDialog. (Emptied and removed MainWindow::onGeneralSettingsChange(), as currently all its contents now are in ImagePlaybackControlDialog.)
• In camera view dialogs, date and time label was removed, as this feature was only relevant in case of fileCamera, but that is now accompanied by the imagePlaybackControlDialog, which also shows the date and time of the image displayed.
• In camera view dialogs, Camera FPS and Processing FPS values are now rounded (adaptively, if above 1 FPS) for better visual comparability.
• A trial counter is added to the bottom of main window (status bar). This is shown only when a camera (single or stereo physical camera, or an OpenCV compatible webcam) is connected, and is used in:
  • csv recording (dataWriter),
  • image recording (for keeping in offline-event-log.csv file alongside recording, written via recEventTracker itself),
  • streaming (dataStreamer).
    Trial counter is safely reset if csv recording, image recording, or streaming is stopped, meaning that if any other of these still exist, the counter will not be reset to 1. It can also be manually forced to reset in Settings menu (and also via a remote command). This counter in mainwindow status bar does not show up when an image recording in opened. Trial counting in case of image playback is shown in ImagePlaybackControlDialog, and is read from an offline-event-log.csv file, which is automatically loaded if found in the image directory opened (or in directory 0 of the recording is stereo). Its value is refreshed on each displayed playback frame.
• ResizeableRectItem instances (thus all pupil detection ROIs) now have a minimum size. Also it keeps 4:3 aspect ration when resized, but this rule can be overridden by holding down the "alt" key.
• Camera view dialogs' "Show" menu has been added a new section in the bottom, where the user can enable a fill overlay inside the detected pupil ellipse. The color of the fill is between green and red, corresponding to 1 and the customizable "lower threshold" value of either the confidence, or outline confidence value outputs of pupil detection.
• Camera view dialogs' "ROI" menu was renamed to "Pupil Detection ROI" for clarity, and moved into a newly added menu called "Pupil Detection" in the top of the dialog. This menu now also contains a new submenu, where the user can adjust the maximum expected pupil size for Automatic Parametrization configuration of algorithms - where the size is expressed in the relative size /ratio of pupil diameter, relative to the smaller dimension of the pupil detection ROI rectangle.
• Pupil detection now uses different "image processing modes" (I called them procMode in code or proc.mode in comments), and can work differently on the incoming images, according to how many pupils the program should be tracking. These needed separate pupil detection ROIs, which needed camera view dialog and videoView codes to be changed. In line with this, I changed several parts and added new code to pupilDetection class, and also algorithm-specific pupil detection settings dialog codes. The most important change is that no matter which processing mode the incoming image has gone through, pupilDetection will always emit the same signal, and the detected pupils (one, two, or four Pupils) are now packed into a vector of Pupils, whereas the emitted signal also contains an integer that refers to the enum which specifies which processing mode was used during pupilDetection - this way every slot it arrives into, can properly deal with the content. Slots in GraphPlot, DataTable, DataWriter (and a new added class called DataStreamer) have been changed to deal with these new types of signals.
• Pupil detection outcome, as well as the ROIs used for pupil detection are not anymore drawn onto the image inside pupilDetection class, but in the videoView instance(s) that correspond to the camera view of the opened camera. This gives the advantage that the user can be informed instantly of their actions regarding changing pupil detection ROI sizes and locations.
• Automatic Parametrization is a new config option in pupil detection settings dialog, added to pupil detection settings GUI code of each algorithm. The parametrization calculations are done in pupilDetection, and are based on the maximum expected size of the pupil related to the smaller dimension of the pupil detection ROI rectangle. Even if multiple ROIs can exist (in case of e.g. single camera image, using single-image-for-two-pupil proc.mode), all existing algorithm instances (correpsonding to these ROIs) are parametrized the same way. This is because of the preassumption that:
  • case 1: both eye(s) seen areas are located in the same distance from the camera lens, and all ROIs have the same size
  • case 2: eye(s) seen areas are in different distances, but ROIs are differently sized to bound the eye(s) around in the same extent
    Automatic parametrization has a graphically configurable "Expected max pupil size" setting under camera view dialogs, in Pupil Detection menu, and "Automatic Parametrization" submenu. The current setting can be viewed using an overlay on the eye image.
• Ensured several "!pointer" checks in mainwindow.cpp by default-setting (and re-setting) the pointer to nullptr.
• Fixed (afaik) that checkboxes in generalSettingsDialog (and other bool values elsewhere) were not read out from QSettings /application preferences correctly. I think Qt saves boolean values as "true"/"false" strings, but fails to parse these strings to valid true/false bool outputs (Qt 5.15)

---

Further notes:

• I think trackingOn, recordingOn, etc. bools should be avoided in mainwindow, and checks for an instance existence, like !dataWriter should be used (dataWriter can only exist, when a recording is on), and in cases when the instance is never nullptr (e.g. pupilDetection instance), its methos should be called to check whether isTrackingOn(). I changed a few bits of the code, but have not removed/changed all checks like the ones I mentioned.
• I introduced setFixedWidth() calls for several widgets like spinboxes or comboboxes, or moved two lines into one (relocated to a little horizontal layout), or sometimes shortened or abbreviated text to let the widgets fit on a smaller screen area. I also extended a few labels to clarify their meaning where I thought it was necessary. (E.g. "calibration" is now mentioned as "Camera calibration" to easily distinguish from the concept of gaze calibration, which is shortened to "calibration" in the eye-tracking jargon, however it may be added to program features in the future.) I hope these changes also work on non-windows target platforms, but I do not have a Mac to test it.
• The added new Qt5 dependencies are: Qt5Network, Qt5Xml

---

Todo/fix/suggestion:

• "mirrored" camera image is now handled as a whole different pupil detection proc.mode, while it would also need a different way of camera calibration too (which I did not implement)... Thus, it may be easier to not handle this as a kind of proc.mode, but rather a different kind of camera. E.g. a mirroredCamera class could be created, which would partially impersonate a stereo camera, using a split-image single camera, and the getType() of the camera would also return a new enum value, declared especially for this camera.
• Eliminate the following bools and replace with nullptr checks or calls to methods that tell the state: recordOn, recordImagesOn, streamOn, trackingOn, etc...
• There could be a kind of large textbox that shows (and logs?) the received Remote Control commands.
• Hitting an "enter" can do unexpected things (possibly because certain dialogs don't specify any widget in focus, or button behavior /eventfilter for these). Find and fix these?
• Camera image acquisition ROI settings spinboxes (in single or stereo camera settings dialog) should trigger the values to change only when the change was committed /editing finished, not on every new digit entered.
• There should probably be a table view (and a new dialog for that) which shows the recorded/loaded events handled by recEventTracker.
• Camera view dialogs' "Fit, 100%, +Zoom, -Zoom" functionality is not yet tested with all the other changed videoView codes.. but I think it should work fine.
• Camera calibration should be made for a full camera image (when image acquisition ROI is maximal), and when smaller acq. ROI is selected, the already done calibration could be used with ease.
• Image acq ROI settings should allow locking x to y (keeping any aspect ratio).
• Camera temperature checker class lacks an on/off checkbox and "check interval [sec]" spinbox settings in general settings dialog.
• Add nofitication message if many subsequent frames get frame lost: "Several frames got lost and not received from the camera. Please chack camera connection. Be sure to use an active (power supply backed) cable for long distances."
• Add all necessary info and pupil detection algorithm settings to meta snapshots saved upon CSV data recording is started.
• Support FLIR, AOS, JAI or other brand industrial cameras.
• DataStreamer could support "stream-on-demand": when "one" measurement is sent in response to a "query" message received. Also minimal pupil size filtering (interpolation based on confidence-thresholded time series-data) could be done on the fly. In this way, PupilEXT could be easily integrated into neurofeedback paradigms or devices that have low computing capacity or that run a program written by non-IT experienced staff.
• Allow to stream (in an on-demand fashion) a coarsely-binned power spectra of the pupil signal, e.g. up to 6 hz. This would allow to use the program in "pupil frequency tagging" paradigms in brain-computer interface research with ease.
• Allow tracking the eyes, and fit a bounding box to them, which will be used as pupil detection ROI. A "reposition"/key frame could happen in every second or two, which resizes and relocated the ROIs this way (and autoparam re-run).
• Implement some entry-level gaze detection and all the things that come with it, e.g. screen-calibration.
• The program should be able to interpret not only "trial increment" messages for temporal markings, but other kinds of "trigger" events (not referring to camera image acq. triggering), like EEG devices where custom trigger markers can be used, designated by numbers between 0-255.
• EDIT: Let image recordings be saved into / read from a lossless encoded video file.
• EDIT: Upgrade to newer Qt and Pylon version.

---

Other asap check /urgent todo (also mostly to myself):

• Fix pupil detection ROI setting (rational & discrete distinction). Also, does pupil detection ROI resize always keep to the 4:3 aspect ratio correctly?
• "Map" data structure could be used in program codes, where I did not use this.
• If there are no existing values in the QSettings (ini file) of the application, pupil detection ROIs can behave strange. Fix
• When pupil detection stops, and proc.mode gets changed, these (if exist) should be changed accordingly!
  • DATA WRITER
  • DATA STREAMER
  • DATA TABLE
  • GRAPH PLOT(s)
• When calibration window (or maybe sharpness too) get closed and reopened, the program chrashes (I think this existed in the 0.1.1b version already). Fix this
• In case of stereo image recordings, where should the meta-snapshot file be saved: in folder 0, or folder 1, or their parent?
• Automatic parametrization should be checked whether it is really working always as expected. Does it surely work when someone just ticks/unticks "use ROI preprocessing" in pupil detection settings? Does it work when someone changes pupil detection ROI on the fly? Etc.
• Calibration: does it really work with different proc.modes?
• Stereo camera: does it really work? Camera triggering works fine still?
• EDIT: Does "Processing FPS" really show good values? Does image playback control dialog's "Acquisition FPS" label show good values?

[BZandi]

Dear Gábor, I tried to check the code in your private GitHub repo, but I did not find it. Could you send me another invitation?

[kheki4]

@BZandi Ok I checked it, somehow the invite disappeared, so I did it again. Now it says "pending invite" and should be working I hope. It gave me this link: https://github.com/kheki4/Open-PupilEXT-upgrade/invitations

[kheki4]

I committed a little today which may be important: in the first uploaded version I mistakenly moved instantiation of serialSettingsDialog, remoteCCDialog, and streamingSettingsDialog up in mainwindow declaration, which caused them to crash when the user tried to open a COM port. Now I repaired it. Please consider this Mr. Zandi or see corresponding changes in github

[kheki4]

Dear All,

Please excuse me for the ~1,5 years delay concerning the new (v0.1.2) release of PupilEXT on the Experimental-Community-Version branch. We will be uploading the release and applying for a pull request from our fork with @sasfog during July or at last before the middle of August.

Some of the "todo" nice-to-have features mentioned earlier in my comments will still not be added, though many of them (and even more that are not mentioned here) could be successfully added to the software, and will be contained in the new release. So far we have successfully built for Windows 10 x64, MacOS Monterey, and Ubuntu 22.04 LTS with working Pylon integration, and we expect to release builds for these. Also note that Pylon version will be raised to 6.2.0 from 6.0.1 in the new version, though Qt 5.15 LTS stays the same.

An open-source hardware for the project is also on the way, though it is expected to be published along with another later release, likely in 2025 spring, but surely no sooner than this winter. A previously promised "mirrored stereo" camera option unfortunately will not be included in the v0.1.2 release yet, so the stereo feature will still be usable only if you have 2 physical camera devices. Though as soon as the files and tutorial for a "1 camera + 1 IR light source" hardware version is done, my next thing will be to finish the 3D prints for the optics of the mirrored version.

More updates will come in the next month, stay tuned! :)

[kheki4]

The release is done! :) Pull request is made. The release files are at the moment uploaded here:
https://github.com/sasfog/Open-PupilEXT/releases/tag/v0.1.2-beta

Yet it only contains the Windows deployment, but MacOS and Linux are on the way. (They all compile and run smoothly, but somehow I could not get the MacOS installation to succed on a fresh Mac - probably there is a problem with its dependencies/embedded frameworks, I will get back to that in a few weeks. And when done, I also make the Linux version and upload it.)

If anyone is interested, our efforts are also summarised in a poster, and will be on display at ECEM 2024 now in Maynooth.
A pdf version of it is available here: https://drive.google.com/file/d/1rRivRrWCri5qHied5Y59O8wxgaOPgh9r/view?usp=drive_link

[BZandi]

Thank you for the pull request. I merged the pull request. Could you please also check whether you need to update the licensing terms or the list of included open source frameworks (see the readme file)? Further it might be good to link your poster publication into the readme with a reference to the new version number. Please also check the instructions inside the readme file if the build process changed in the new version.

[kheki4]

Yes excuse me, I forgot to update the license section of the main readme. The new dependencies we added from Qt is the Network and Xml ones, and their info page says the same GPLv3 license applies to them as other Qt modules. Any other bit of code I used from SO or someone's blog are always cited and mentioned with a link and date of last access. Attributions for icons graphics are also mentioned in the 3rdparty licenses markdown file, and now also updated in the main readme file. I tried to do my best at making the license matters clear in the codes and the markdown, but if you happen to notice a problem I appreciate if you point to it, and I will correct it.

And indeed in the readme I forgot to update the displayed contents of CMakeLists and the Nucleo code that has a 1 line change. I made the changes and a new pull request to the official Experimental-Community-Version branch in your repository. I also updated the readme in our release zip, it should be fine.

I was thinking about citing my poster, but at the ECEM conference they do not tend to upload it or give it a DOI number, so I thought it might not be important to mention it. But thank you for the encouragement :) I uploaded it to my researchgate profile and placed a citation in the readme.
(Also this/next year we are planning a study that compares experimental findings based on PupilEXT and an EyeLink eye tracker that record the eyes of the same participants in parallell, for comparison - and that we plan to publish as an article, which will be centered around introducing a new version of the software, and I will definitely mention that in the readme and about dialog as well.)

[kheki4]

Although, I think I cannot add a release to your repository, so only you can do it. If you wish you can still wait until we finally make the working installer/deployment for Mac and Linux too, or you can upload the release as it is right now by copy pasting the one on our fork. Really as you feel comfortable.
The current state of the release with the new tag on our for is here: https://github.com/sasfog/Open-PupilEXT/releases/tag/v0.1.2-beta
Thank you!