Multiple issues with gettings durations for events from Open Ephys binary files

[johnmbarrett]

Describe the bug
OpenEphysBinaryRawIO._parse_header refuses to extract durations when the number of rising edges detected exceeds the number of falling edges, even though there is enough information to compute almost all durations in this case, and also incorrectly assumes that successive events always have alternating polarity.

To Reproduce

1. Download this OpenEphys dataset: https://drive.google.com/file/d/1Hr3-GFOpOkNc1hgXdVr5HTunchQm4enw/view?usp=drive_link
2. Unzip the dataset somewhere
3. Run the following code

from neo.rawio.openephysbinaryrawio import OpenEphysBinaryRawIO

folder = # fill in the folder you unzipped the data to

io = OpenEphysBinaryRawIO(folder)

io._parse_header()

timestamps, durations, labels = io._get_event_timestamps(0,0,0,None,None)

Expected behaviour
The correct durations are returned for all events

Actual behaviour
durations is None

Environment:

• OS: Windows 10
• Python version: 3.9
• Neo version: Open Ephys: read events from all streams #1430 (you can't load all events from multistream datasets without this PR)
• NumPy version: 1.26.2

Additional context
For the first problem, the check on line 245 of openephysbinaryrawio.py is unnecessarily stringent. It should be less than or equal, not strict equality.

Moreover, the logic in this section doesn't work when events from multiple binary channels are interleaved on the same event stream (which is allowed by the Open Ephys specification and happens for e.g. data from an Intan RHD2000 USB evaluation board), as it incorrectly assumes that events alternate between rising and falling. However, if multiple channels are interleaved, then two rising or two falling events from different channels can follow each other, and so the duration calculation on line 246 is wrong. In the example dataset, this happens for the 26th & 27th events, in which a falling edge on channel 2 follows a falling edge on channel 3. A better approach would be, for each rising edge, to look for the next falling edge with the same absolute state value (and either drop that event from the list or assign it a NaN duration if none is found, rather than Noneing out the entire durations array)

[alejoe91]

@johnmbarrett would you have time to make a PR and propose a fix?

[vigji]

Reporting here similar issues.

I am opening OpenEphys-saved data from a NIDAQ board where I acquire two digital inputs. When I load it using spikeinterface - which relies on this afaik - durations are all messed up as it seems that the falling edge of one signal cuts the duration of the other signal (parts of the recordings where one of the digital signals is just off have no issue). @alejoe91 can you confirm this could be the problem?

any plans on fixing this upstream? ATM I have to write custom loading from the events folder where everything else is loaded with spikeinterface :(

[alejoe91]

HI guys, this fell a bit out of my radar, my bad!

I'll add it to my todo list and try to propose a fix by the end of next week.

Cheers

[vigji]

any update here @alejoe91 ?

[alejoe91]

Hey @vigji

Sorry I haven't had time to work on this. Any chance you want to give it a try yourself and make a PR?

[vigji]

Sure! On it :)

[vigji]

@johnmbarrett would be great to know if #1603 fix the issue for you! (I can't download the 17Gb right now)