-
Notifications
You must be signed in to change notification settings - Fork 191
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
Kilosort4 Wrapper #2529
Kilosort4 Wrapper #2529
Conversation
Co-authored-by: Zach McKenzie <[email protected]>
One other point about the save to binary that might be interesting is that Mountaintsort5 had a speed up by switching to using the cached binary (see this). Kilosort also recommends using a binary file as well (but more so that you can use their gui and phy which are not really our concerns per se). I'm wondering if it might make sense to give the user an option to do this with write to binary to make this completely compatible with a Kilosort4 workflow for people or not. I could see arguments either way (and SI already has the |
Thanks Zach, that's a good point especially regarding the phy output. In my view, we should be as agnostic as possible to the sorter and just use the spike times outputs, so we can better compare and unify pipelines regardless of the sorter. In this spirit, I would rather not add this option and "force" the user to postprocess and export in SI. What do you think? |
I think that's completely fair for the library. :) I guess if there are a lot of issues requesting something like that then there would be an impetus to do it and it could be reconsidered, but I agree this is the better initial choice. I think keeping the library agnostic is a good guiding principle, so thanks for framing it that way. Makes a lot of sense. (And I already do all my postprocessing here anyway :) ). |
Looks like the docker image is private right now - but with a pip installed KS4 this works as intended. |
It's not pushed to docker hub yet, so it would need to be built locally ;) I'll test it a bit more and publish it |
Well done camarade. |
Yes, same old ;) |
Could you also add it in documentation and the installation sorter page ? |
Right! Will do that on Friday @samuelgarcia |
@samuelgarcia ready to merge on my side. Added installation docs |
np.random.seed(1) | ||
torch.cuda.manual_seed_all(1) | ||
torch.random.manual_seed(1) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not a great way!
I merge this now in the main. |
Fixes #2527
Kilosort now has a SpikeInterface Wrapper (
RecordingExtractorAsArray
), so we don't need to save to bin!I had to port subsections of the
run_kilosort
function to allow to:Added tests for all cases.
The parameters and descriptions were ported from their parameters definition.
One last comment:
The
RecordingExtractorAsArray
concatenates multiple segment. I think we should handle this externally to "unconcatenate" the sorting output, so I sethandle_multi_segment
to False.