Roadmap question: deep inter-session unit matching / UnitMatch-style matching

[adamwea]

Is implementing deep inter-session unit matching (UnitMatch-style / chronic alignment) on the SpikeInterface roadmap? If so, what is the expected timeline and preferred integration point (module/API)?

Context: Issue #2626 discusses inter-session alignment workflows and post-hoc unit matching, including compatibility with MouseLand/UnitMatch. Linking here for reference.

I will likely be implementing UnitMatch for my own pipeline regardless, so if this feature is planned I would be happy to contribute an implementation under maintainer guidance (tests + docs included). That way the effort could support both my project and SpikeInterface.

Happy to align on scope and placement before starting development.

[alejoe91]

Hi @adamwea

Thanks for the question! I think that @EnnyvanBeest and team are working to integrate DeepUnitMatch with SpikeInterface. @EnnyvanBeest can you update us on that?

[chrishalcrow]

Hello, we've had some discussions but there's no specific roadmap. We believe the sorting analyzer contains all the information you need to do this type of work.

It seems like the trickiest bit of the design is how to store the data model of the comparison between analyzers. I think there's now vague agreement that some kind of flat format:

analyzer_1_unit_id	analyzer_2_unit_id	confidence
32	64	0.9
33	73	0.8
32	63	0.6
35	66	0.9

This has advantages: you can have repeated units (unit 32 form analyzer 1 is "matched" with unit 64 and unit 63, but with difference confidences); we can add other labels etc. @oliche convinced us this was better than something like storing a confidence matrix of size len(analyzer_1_unit_ids) x len(analyzer_2_unit_ids)

Once we agree on the internal data model, hopefully adding algorithms like UnitMatch won't be too hard, with an API which just takes two analyzers.

compute_matching_unit_match(analyzer_1, analyzer_2, other_parameters...)

Maybe we could have a meeting with you @adamwea about implementation? Would be great if @EnnyvanBeest was also interested!

[EnnyvanBeest]

Hi,

UnitMatchPy (and DeepUnitMatch by extension) should already be working with SpikeInterface.

see for example our SpikeInterfaceDemo.
DeepUnitMatch (see Demo) uses the same architecture as UnitMatchPy, so replacing the specific UnitMatch functions with the DeepUnitMatch functions in that demo should do the trick.

From the probability matrices across all recording sessions, UnitTrack is part of the UnitMatch repository and already assigns Unique IDs (see the original UnitMatch paper for the description of the UnitTrack algorithm, specificallly figure 5).

UIDs = aid.assign_unique_id(output_prob_matrix, param, clus_info)

I guess the question really is, how do we implement SpikeInterface to use these UIDs for post-processing / further analysis. I'm happy to have a meeting about this and tell you how I implement this for my own data analyses, but ultimately I think this is down to how SpikeInterface integrates UnitTrack's UIDs and whether postprocessing is then done using these UIDs or using the original clusterIDs, which probably should be an individual researcher's choice.

[chrishalcrow]

Thanks Enny. Yeah, we'd like to make something internal that will work well with the existing UnitMatch structure (and hopefully make the SpikeInterfaceDemo even simpler), also works with more basic methods (e.g. just using template similarity) and is flexible enough to also potentially work with other tools (like Neuron-Tracking from the Harris lab).

I think your post shows that even just deciding how to label each unit is non-trivial and we need to think hard, and learn from what you've done with UnitTrack in UnitMatch!

[EnnyvanBeest]

That would be great and super useful indeed! Again, let me know if you'd like to meet to help brainstorm. You know where to find me! :)