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

Surface gaze format #18

Open
papr opened this issue Mar 1, 2022 · 3 comments
Open

Surface gaze format #18

papr opened this issue Mar 1, 2022 · 3 comments
Assignees
Labels
help wanted Extra attention is needed question Further information is requested

Comments

@papr
Copy link
Collaborator

papr commented Mar 1, 2022

@cboulay I am currently trying to extend the plugin to support surface mapped gaze. But the one channel_format-per-outlet rule is making life difficult for me.

While in a perfect world, every surface would have its own outlet, this is not feasible for the LSL Relay plugin without intertwining it deeply with Capture's Surface Tracker plugin. I thought of building a flexible outlet following the tidy data approach:

LSL timestamp surface name norm_pos_x norm_pos_y confidence is on surface
t Screen left 0.5 0.5 1.0 True
t Screen right -1.5 0.5 1.0 False
t+1 Screen left 1.5 0.5 1.0 False
t+1 Screen right 0.5 0.5 1.0 True

As mentioned above, I am not able to mix the string column with the double columns (I think). If I understood the documentation correctly, one should be building time-synced outlets instead. @cboulay Would the following outlet layouts conform to LSL best practices? If not what would you recommend? I am only semi-happy with the solution below.

  1. Surface Name outlet (type: string)
LSL Timestamp Surface ID Surface Name
t 1.0 Surface left
t 2.0 Surface right
t+1 1.0 Surface left
t+1 2.0 Surface right

Surface ID would correspond to the string representation of the surface id. Surface ids would be incrementing integers in the order of appearance in the processed data.

  1. Surface Gaze outlet (type: double)
LSL timestamp surface id norm_pos_x norm_pos_y confidence is on surface
t 1.0 0.5 0.5 1.0 1.0
t 2.0 -1.5 0.5 1.0 0.0
t+1 1.0 1.5 0.5 1.0 0.0
t+1 2.0 0.5 0.5 1.0 1.0
@papr papr assigned cboulay and papr Mar 1, 2022
@papr papr added help wanted Extra attention is needed question Further information is requested labels Mar 1, 2022
@papr
Copy link
Collaborator Author

papr commented Mar 1, 2022

One alternative would be to use the original single-outlet design with a string format and using either the string representation for the floats or struct.pack. Both do not seem particularly satisfying to me.

@matinpf
Copy link

matinpf commented Mar 6, 2022

Hi Pablo Prietz,

We are using App-PupilLabs in our research and even your second solution will be great for our goal (because we only have one surface which is a screen).

Could you please help with sharing codes or any implementation hints?

@mitchellsayer
Copy link

@papr Did you ever get this working?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help wanted Extra attention is needed question Further information is requested
Projects
None yet
Development

No branches or pull requests

4 participants