You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently (I believe) the canonical way (e..g in the docs) to perform a sorting pipeline in Spikeinterface is
generate a recording object for preprocessing
pass this to a sorter and get a sorting object
extract waveforms using the preprocessing recording and sorting output. The waveform data is extracted from the preprocessed recording.
(please let me know if this is wrong off the bat)
One problem with this workflow is that in some instances the sorter performs it's own preprocessing, in the case of Kilosort this is saved as the temp_wh.dat file. In this case, the waveforms saved by spikeinterface will not be the same as those in Phy / the true data that was sorted on. I guess this will be similar in any case that any sorter does it's own preprocessing, although I am not sure of the specifics of other sorters.
I wonder what the best approach for this is (if it is indeed a problem) - could it be solved by documentation? Or, should the sorting object hold a reference to the output of a sorter's preprocessing steps (e.g. temp_wh.dat loaded as an SI recording object in the Kilosort case) which waveform extraction can use under the hood? For example instead of:
and under the hood sorting would use temp_wh.dat to extract waveforms from, or whatever other sorter-specific preprocesing file there is. Otherwise, it could load the preprocessing file directly from the metadata in the sorting output, or optionally take a recording object as is done now.
The text was updated successfully, but these errors were encountered:
You can already load the KS pre-processed data as a plain binary file with the si.read_binary() function:
The main "problem" is that the preprocessed data will not contain all channels, as some are removed for lack of activity.
I guess that we could make a KilosortTempWhRecording that loads the preprocessed data and reads the metadata (such as which channels have been removed) from the KS output. Then one can extract waveforms with whatever preferred recording. What do you think?
Currently (I believe) the canonical way (e..g in the docs) to perform a sorting pipeline in Spikeinterface is
recording
object for preprocessing(please let me know if this is wrong off the bat)
One problem with this workflow is that in some instances the sorter performs it's own preprocessing, in the case of Kilosort this is saved as the
temp_wh.dat
file. In this case, the waveforms saved by spikeinterface will not be the same as those in Phy / the true data that was sorted on. I guess this will be similar in any case that any sorter does it's own preprocessing, although I am not sure of the specifics of other sorters.I wonder what the best approach for this is (if it is indeed a problem) - could it be solved by documentation? Or, should the sorting object hold a reference to the output of a sorter's preprocessing steps (e.g.
temp_wh.dat
loaded as an SI recording object in the Kilosort case) which waveform extraction can use under the hood? For example instead of:the call to
extract_waveforms1
would be:and under the hood sorting would use
temp_wh.dat
to extract waveforms from, or whatever other sorter-specific preprocesing file there is. Otherwise, it could load the preprocessing file directly from the metadata in the sorting output, or optionally take a recording object as is done now.The text was updated successfully, but these errors were encountered: