Spiker is an interactive program for off-line spike-sorting of the tetrode extracellular recordings. (If you don't know what an extracellular recording is, this program is probably not for you).
The main advantage of using a tetrode for neurophysiological recordings is being able to simultaneously record from a number of neighboring cells (neurons). More than that: with a tetrode one can reliably determine how many neurons were active in the recording and reliably separate spikes according to their respective neurons of origin. The process of assigning spikes to cells is called spike-sorting.
Data acquisition programs for extracellular recording can be divided into two major categories regarding the way they store the data. 1) those that are continuously streaming the ADC readings to the disk and 2) those that detect spikes in the ADC stream and save only a limited piece of the waveform surrounding the detected spike. We have chosen to implement the first approach for the reasons discussed elsewhere [1].
The input file format of Spiker is a continuous binary stream of signed 16-bit ADC samples (any byte order). Data samples are assumed to be in the following format: for every ADC time tick, samples for all channels are recorded in the channel order (one 16-bit wide word per channel), and this structure is repeated for the duration of the recording. The total number of recording channels in the input file can be in the 1 to 16 range. No information on the number of channels, ADC sampling rate or timing is stored in the file. This allows using Spiker with any data acquisition system that can continuously stream data to the disk (i.e. raw data format). If a fixed-length header is used in the datafile, Spiker can be configured to skip a user-specified number of bytes in the beginning of the file.
To allow processing of multi-tetrode recordings mixed with recordings of any additional data (e.g. synchro signal, field-potential, etc.), channels can be freely arranged in groups for display and processing. Groups can have non-consecutive channels and can share channels. Number of groups can be in the 1 to 4 range, each group can include from 1 to 16 channels.
On opening of the file, the offsets for each channel and the covariance matrix for each set of tetrode channels are estimated from 10 chunks picked at random from the data file. Then, at user's request, spikes are detected in traces by a thresholding procedure. We are using a hyperelliptical thresholding procedure described in [2] with the default value of the threshold factor set at 5. If needed, the threshold can be interactively adjusted by the user: current setting is applied to detection of spikes in the chunk of data displayed in the main window. In the process of spike detection, the amplitudes of spikes at all channels are measured. Peaks at different channels do not always precisely coincide in time, so the search for an extremum is performed on each channel individually. To reduce digitization error, data points are 10 times oversampled around the detected peak using Fourier interpolation over 80 neighboring points, and the amplitudes are corrected accordingly. This step is especially important for low ADC rates (20 kHz and below).
Each spike (event) has a set of associated amplitudes; for a tetrode, there are four such amplitudes. Then each event can be treated as a point in this 4-dimensional space.
The task of a spike-sorting procedure is to determine the number of active cells and to assign events to cells. Tetrode spike-sorting is based on the fact that in the 4-D amplitude space points that were produced by the events originating from the same cell tend to group together. Or in other words if the combinations of spike amplitudes were unique for a given cell (which is usually the case) and if there were no variation in the amplitudes of spikes coming from the same cell, we would see in the 4-D amplitude space just a number of points corresponding to the number of active cells. As there is always some variation in the amplitudes (see [2] for the discussion of its origin), we observe some kind of clouds (clusters) of points. So the spike-sorting procedure should find the number of distinct clusters and to assign events to clusters. In spiker this task is performed manually. To visualize the distribution of points in the 4-D space, we, like many others, project this space onto 6 two-dimensional planes (the number 6 is given by the number of different pairs of amplitudes). In other words, for the plane defined by channels X and Y, for each event a point is plotted at coordinates Ax and Ay, the amplitudes on the two channels (the remaining two amplitudes are disregarded for this plane). Thus, each event generates 6 points, one point per plane. Click on the figure below to view a snapshot of Spiker window used for clustering.
The user can draw an ellipse around the points and mark them as belonging to a particular cluster, and this marking will be seen simultaneously in all displayed planes. Spiker also allows to work with the distribution of the amplitudes observed from a different angle in the 4-D space (Hadamard transform [1]), which in many cases produces better separable projections of clusters. User can also switch between a "point-per-event" representation and "density" representation, where density of events is represented by the brightness of the point [1]. "Density" representation provides better separation of clusters in case the number of spikes in the file is big (above few thousand).
After clustering is done, the results can be saved in a number of different formats. All output files are written as ASCII text. Records are separated by a new line character(s). Fields in the record are space-separated. This makes files platform-independent and easy to view and debug.
Implemented formats :
The formats above show the content of a single record. The number of records is determined by the number of spikes (formats 1-3) or the number of clusters (format 4). Format 4 is somehow more complicated and will be described in more detail later.
Spikes saved in the format #1 can be loaded back in spiker.
Spiker allows to view the data in multiple ways:
Spiker is written in C using the commercially available "Galaxy C 2.6" environment. "Galaxy C" is essentially a C library that allows one to write platform-independent programs that have "native" graphical user interface. Galaxy also comes with a program that allows to design user interface in a WYSIWYG manner. By compiling the same code on different platforms (using platform-dependent libraries) one gets platform-independent code. We have compiled versions of Galaxy for Windows 95/Windows NT and DEC Alpha Digital Unix .
Galaxy was a product of Visix that went out of business in March 1997. Another company (based in Brazil) - Ambiencia seems to take over. At the time of this writing it is not clear if they have special educational pricing as Visix did - $500 per license per platform. It does not seem likely that Galaxy has any future in it, but since a lot of investment has been made we will continue the development of spiker using this library.
Spiker shares code with two other programs - spcom (command-line based automatic tetrode spike-sorter) and spmex (Matlab based automatic tetrode spike-sorter). Both programs were written by Brian D. Wright. All three programs share the same "engine" i.e. basic data structures, file I/O subroutines and spike-detection subroutines. This allows to modify the "engine" of all three programs at the same time, independently of the user interface.
Spiker
The official site for spiker is http://millerlab.ucsf.edu/. There you can get the latest version of the program and the manual. If you wish to receive the source code, please contact Sergei Rebrik, Brian Wright or Ken Miller.
Spiker was created in the laboratory of Ken Miller, the W.M. Keck Foundation Center for Integrative Neuroscience at the University of California, San Francisco. It was originally written by Sergei Rebrik. New spike-marking procedures, feature detection and command line and MEX interfaces written by Brian D. Wright. (Please note that command line and MEX interfaces are not covered in this manual). Special thanks to Al Emondi and Svilen Tzonev for testing the program and for suggestions on its improvement. Authors would also like to thank Ken Miller for his support of this project and for many useful ideas.
This work has been supported by grant R01-NS33787 from the NINDS, and by the Searle Scholars' Program (K.M.).