in the help text of function "pspm_pupil_correct_eyelink", it says "options.channel" should be either "numeric" or "string", but the function actually cannot take numeric input as set in the function "pspm_options" (only *Char).
would like to have an option to process both eyes (currently users have to loop for both eyes if they still want to combine pupil data later).
pspm_load_data issue:
this function cannot load preprocessed or combined pupil channels properly, because we have taken out all "_pp" channels (in the preprocessing functions, but not in the function "pspm_init"), but in the within-function function "get_chans_to_load_for_pupil", it is still parsing "_pp" as preprocessed channels or combined channels.
additionally, when loading pupil_l or pupil_r, the default setting is to take unprocessed channels (line 340), which conflicts with the within-function function "get_chans_to_load_for_pupil" help text (points 3 and 4). And for users, this default setting is not changeable. However, as we have taken out all "_pp" in channel types, this conflict did not influence the result, but it is very confusing.
pspm_find_valid_fixations issue:
unmatched helptext for "options.eyes" compared to the actual valid values used in the function (i.e., "combined" vs. "all"); to be noted, in the practical analysis, setting option.eyes to be "combined" should be interpreted differently as "all".
if "combined": I want to run the function for the combined eye data (and so combined gaze x/y channels are required; another option would be to make it similar as in "pspm_pupil_correct_eyelink", we can say that this is not possible for combined pupil data).
if "all": I want to run the function for all eye channels.
For the current codes, setting options.eyes to be "combined" works as if options.eyes = "all".
And once more, find_valid_fixation is the only function (as far as I am aware) that takes the first channel if multiple channels with the same channel type exist, while the other functions always take the last channel.
pspm_gaze_pp issue:
input argument unclear to users, especially "options.channel". Instead of taking "gaze_x_l/r" and "gaze_y_l/r", taking automatically both x and y coordinates for the selected eye(s) makes more sense.
All of these with one exception are fixed in the current develop branch. Feature request 2 for pspm_pupil_correct_eyelink will be implemented in a future PR.
Summary
pspm_pupil_correct_eyelink issue:
pspm_load_data issue:
pspm_find_valid_fixations issue:
Technical Info