spike markers

[tsieger]

I propose to add an option that would show where in the original signal reside detected and the currently sorted spikes. This could be achieved e.g. by plotting small vertical bars at individual peaks, as can be shown in the amplitude trace here:

This option is extremely useful e.g. when considering whether to accept or reject a cluster of low-amplitude spikes: the position of such spikes, as revealed by the spike markers, can demonstrate that such spikes pose artifacts or spurious peaks, not real spikes (as was the example case above).

I've sketched an implementation of this feature and am sending a pull request.
At the same time, I think it would be nice to have this option configurable (e.g. using a parameter in the parameters file?), but I did not want to change much code, so if you decide to merge my proposal, please consider making it configurable somehow (perhaps disabled by default?).

Also, please note that in plotSpikes.m, I got the signal to plot from handles:

data_handler = readInData(handles.par);
[xd_sub, sr_sub] = data_handler.get_signal_sample();

which may not be optimal. Maybe, the signal is cached somewhere, and can be retrieved much easier from there?

[ferchaure]

It's a nice idea, I think that something like that could be more useful before the clustering
... like a tool after Get_spikes() for check the detection and choose post-detection thresholds (maximum and minimum).

You are right, use readInData() for this isn't a good idea. Maybe save in a cell all the little lines ploted when you call Plot_continuous_data and then only change their colours in plot_spikes. In that case you don't have to load the signal sample in each call to plot_spikes.

[tsieger]

Thanks for the suggestions.

I've cached the signal in USER_DATA. Caching the spike markers alone would not suffice, as I replot the whole signal on each call to plot_spikes. (This is because IMHO plotting only the spike markers in different colors over and over again (in the "hold on" mode) would degrade graphics performance.)

Using spike markers right after Get_spikes to check detection results would perhaps require to split the processing (spike detection followed by sorting) somehow? I don't dare to do that given my limited insights into wave_clus. After all, spike detection results can be visualized after spike sorting, using the spike markers.

[ferchaure]

You can change the colour of the spikes markers after without plot again and again:
p = plot(1:10);
set(p,'Color','red')

Check the file batch_files/Get_spikes, we use it for split the processing.

[tsieger]

Thanks, I adapted the code: now I plot spike markers only once and color them according to the current clusters.

[sevgiozturk]

When this spike marker property will be available? It seems so sexy :) Actually I need that property to exactly see the spikes in a cluster and find out its overall frequency in whole raw data.

[ferchaure]

We won't use this idea because the filter of detection and clustering aren't necessarily the same and this plot could make the things a bit confusing, and we plot just a minute of downsampled raw data (otherwise more time and space will be needed). After saving the results in a times you can easily calculate the frequencies of the clusters.

[tsieger]

I agree with Fernando that inspecting spikes in individual clusters and computing their frequencies could be much more straightforward using a dedicated code. Also, I concur with the reasons why the idea of spike markers is not as sexy as it it seemed to be earlier.

By the way, if you are curious enough, there is a prototype implemented in my wave_clus fork: https://github.com/tsieger/wave_clus/tree/spike_markers, but note that this code has diverged from the official wave_clus and I would not recommend to use it in production.