SpikeInterface / SpikeInterface/spikeinterface

A thread to discuss inter-session alignment.

Open
#2,626 15 comments 4 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

discussion
Dominant language
Python
Stars
847
Forks
280
Avg merge
3d 9h
Merged PRs (30d)
29

Description

Following a discussion on the Slack channel about inter-session alignment I thought I'd start an issue to summarise / discuss these things and come up with a plan on how this could be handled in Spikeinterface.

There are a couple of (not necessarily mutually exclusive) approaches:

1) post-hoc unit-matching
This approach matches units from independently sorted sessions. Current approaches includes Unitmatch. SI and Unitmatch teams are working together to ensure compatibility such that SI-sorted data can be easily read in Unitmatch. There is also the approach outlined in this paper which looks interesting. Typically the motion correction in these methods relies on putative matches between units across sessions, which may fail in the presence of large drift. Therefore alignment of either the traces (pre-sorting) or templates (post-sorting) across sessions, would compliment these methods.

2) Concatenating sessions and motion correcting
Another approach is to concatenate two sessions together and perform motion correction as if they were a single session, then sort. A concern is how current intra-session methods will perform in the presence of significant drift between sessions (manifesting as a sudden, large 'jump' in the middle of the concatenated recording). In the NP2 paper the Kilosort team suggest this approach does not work so well with the iterative template method*. In the Dredge paper this approach appears to be used successfully. It would be interesting to see at what level of inter-session drift (linear and nonlinear) this approach fails for the available methods. I guess the machinery for such tests has already been largely developed here.

3) Alignment of raw data pre-sorting
This approach is described in the NP2 paper, roughly it goes like 1) within-session motion correction for two sessions 2) compute drift between session and add compensation to within-session offsets 3) interpolate. In theory it should also be quite possible to do with the existing correct_motion machinery, just requiring some additional logical to incorporate inter-session registration offsets prior to interpolation.

4) Alignment of template waveforms post-sorting
This approach is related to post-hoc unit matching (1) specifically. For these methods, instead of interpolating the raw data based on estimated inter-session drift prior to sorting, only the templates are shifted prior to unit-matching. (@alejoe91 I think this is the idea you had at the Unitmatch meeting, if I understood correctly). This should have the same effect as (3) for unit-matching but would be much faster.

In terms of action-points, to my knowledge (1) is actively being worked on but (3) and (4), as well as validation discussed in (2) are not. Therefore supporting these inter-session approaches in Spikeinterface might be a nice idea if others think they have utility.

* Kilosort team suggest this approach does not work well

Chronic recordings
For chronic recordings, we tried to concatenate the raw data files and run the Datashift algorithm as
described above. The results were not always satisfactory, especially when the recording sessions were
separated by weeks.

from here.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the existing correct_motion machinery referenced in the issue and compare the four proposed inter-session alignment approaches. Establish which approach and validation scope the project will support, including drift levels and session types; the issue does not yet name files, tests, or a completion criterion.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
data
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.