Made 3 important hidden parameters visible to the user #809
+56
−3
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
Hello!
In my experience using kilosort, I've had to dig into the code to understand the output I was getting. I found and documented three parameters that impacted the performance of the algorithm:
loc_range
,long_range
, andmax_peels
. I've tested that these work with the GUI and with the API. Also, I've added a warning at the DEBUG level of the logger during matching pursuit.Universal Template Parameters
loc_range
andlong_range
control how far to look in channels and time around a spike to determine (1) if it is a maximum (loc_range
) and (2) if it is isolated (long_range
). These were hard coded toloc_range = [4,5]
andlong_range = [6,30]
, but the user should be able to adjust these if (1) their sampling rate demands different ranges of samples and (2) if the organization of channels in their binary is non topographic. That is, adjacent channels in the binary may not be adjacent in the probe, but the peak detection and isolation treats them that way. This is the case for my data, so I've been running the algorithm with the channel range set to 0 to improve the construction of universal templates.Matching Pursuit:
max_peels
The number of required iterations of matching-pursuit to detect all spikes varies depending on the network properties of the recording. In my data, the network oscillates between quiet and high frequency states. During the high frequency states, there are many overlapping spikes that required more than the hard coded 100 iterations of matching pursuit. For my particular data, I increased the iterations to 500 to detect most spikes during these network bursts.
To make this more transparent to other users, I've added this as a parameter and added a warning using
logger.debug
to warn the user when spikes are detected on the last iteration of matching pursuit.Modified Files
parameters.py
: Added entries for the three parametersgui/settings_box.py
: Added handling for the list format ofloc_range
andlong_range
spikedetect.py
: Added code to fetch theloc_range
andlong_range
parameterstemplate_matching.py
: Added code to fetch themax_peels
parameter and emit a warning