AllenInstitute / AllenSDK

code for reading and processing Allen Institute for Brain Science data
https://allensdk.readthedocs.io/en/latest/
Other
335 stars 149 forks source link

spurious omitted stimuli at beginning of VBN sessions #2577

Open corbennett opened 1 year ago

corbennett commented 1 year ago

Describe the bug Three VBN sessions begin with 'omitted' stimuli: 1052342277, 1052530003, 1115077618

For each of these sessions, the omitted stimulus is reported to happen before the beginning of the behavioral task. This shouldn't be possible, and likely reflects some sort of camstim error with appending frames to the omitted flash frame log. There are other sessions that begin with omitted stimuli but don't show this bug.

To Reproduce Load one of the three sessions above. Then with the following code you can see that 1) the first stimulus is omitted, 2) it starts on frame 0 and 3) its start time precedes the first trial start time:

stim = session.stimulus_presentations
trials = session.trials
first_trial_start = trials.iloc[0]['start_time']
first_stim = stim.iloc[[0]]
print(first_stim['omitted'])
print(first_stim['start_frame'])
print(first_stim['start_time'] - first_trial_start)

Expected behavior There is a 60 frame buffer at the beginning of every behavior session in the current VBN release. The first stimulus should start on frame 60 or 61 (which it does for all other VBN sessions). This should always come a little after the first trial start time (~50 ms).

For these three sessions, we should remove the first row of the stimulus presentations table since it's misleading. We should also add some logic to filter these out for all subsequent sessions. I think for now the sufficient criteria are that the first stim is an omission and precedes the first trial start. But I'd like to test it with the ~3k behavior sessions.

Actual Behavior For these three sessions, the first omitted stimulus is reported to occur on frame 0. This puts it almost 1 full second before the first trial starts.

Do you want to work on this issue? Yes. Happy to help test/write a filter.

morriscb commented 1 year ago

Hi Corbett, looking at this issue it seems to be a bug we can address after we update the data to VBN2.0. It doesn't look to be a show stopper (indeed it was released). Is that the case?

Also, would this be better addressed on the data side instead of use writing a filter to remove these columns. Indeed this seems to be an issue with the pkl file.

morriscb commented 1 year ago

We think this is fixed in the code path for VBO. Just need to use the same path in producing data.