Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposal to implement a sorting_analyzer.merge_units() syntax #3043

Merged
merged 369 commits into from
Jul 15, 2024

Conversation

yger
Copy link
Collaborator

@yger yger commented Jun 19, 2024

This is WIP, and it can be discussed, but the goal of this PR is to implement a sorting_analyzer.merge_units() call that will work as the select_units() one.

Currently, this is only working for some extension, but i'll finish all of them while the PR remains in draft mode. This could be super useful for the GUI and/or for meta merging at the end, since ideally we want to be able to merge units with as few recomputations as possible, given all the precomputed extensions of a sorting_analyzer.

Currently, merges should be given as dict {unit_id : list_unit_ids_to_be_merged}, but this could be disscussed. In this current view, templates are then given as means of merged templates, and i'll do the same for positions. Cross-Corr can only be recomputed for the merged units, ...

  • random_spikes
  • waveforms
  • templates (as weighted sum of merged units)
  • unit_locations (as weighted sum of merged units)
  • spike_locations (should be discussed, since we need in theory to check the peak channel of the templates)
  • amplitude_scalings
  • principal components
  • template similarity
  • quality metrics
  • cross-correlograms
  • isi
  • noise levels

In all these functions, no censor period is applied, but after discussing with @alejoe91 it was noted that maybe this would be worth considering. Let's discuss that @samuelgarcia @alejoe91

@yger yger added enhancement New feature or request core Changes to core module labels Jun 19, 2024
@yger
Copy link
Collaborator Author

yger commented Jun 19, 2024

Some questions remain. When we do a merge, do we want to add the possibility to remove spikes that would violate some refractory period? If this, this might make evertyhing a bit more complicated. Also, for some extensions (such as template, unit_locations) I made the choice to use the mean average merges, but this could be discussed. For the template_similarity merge, should we recompute, or just take a sliced value? Minor details that need to be discussed

@zm711
Copy link
Collaborator

zm711 commented Jul 9, 2024

Perfect thanks @yger.

@yger
Copy link
Collaborator Author

yger commented Jul 11, 2024

Thanks for the tests! Actually I made something very similar, but @samuelgarcia told me not to push anything so I was waiting for his green light.... But it will barely be ready for the release

@alejoe91
Copy link
Member

@samuelgarcia curation docs updated! Ready to merge on my end

@alejoe91 alejoe91 merged commit fe74d45 into SpikeInterface:main Jul 15, 2024
15 checks passed
@yger yger deleted the merging_units branch July 18, 2024 20:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
core Changes to core module enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants