Table of Contents


overlap - overlap correction procedure for ERPs (event-related potentials)


overlap command-file [-s starttime] [-e endtime] [-r regularization-factor]


overlap applies Anders Dale’s overlap correction procedure to the ERP data as described in command-file (see "Command File Format" description below).

The general idea is that you have an experiment with some sort of stimulus event and a corresponding response event. The stimulus and response events occur closely enough to each other that the Evoked Potential elicited by the stimulus event is contaminating the Evoked Potential from the response event, and vice versa. The Overlap Correction Procedure attempts to tease apart the two potentials giving you an estimate of the contribution of the Stimulus Potential to the Response Potential (and vice versa), and also giving you corrected epochs with the overlapping components removed.

Overlap watches the log file flags for each event being considered, and ignores an event if its artifact rejection flag is set. That being the case, you should take care to use the -x option when running the avg(1) program with an artifact rejection file to create average files that will subsequently be processed with the overlap program. The -x option of avg(1) sets the artifact rejection flag in the log file for events that were not included in the average due to artifacts. If you fail to use the -x option of avg(1) , the overlap program will simply include all events from the binlist file you specify. (See the "COMMAND FILE FORMAT" section for a description of how binlist and log files are specified).

Command File Format

The command-file is used to tell the overlap program where the data with overlap contamination can be found, and where to put the corrected data. The overlap program needs to know 1) the name(s) of the ERP average file(s) where the data can be found, 2) the name(s) of the log and Bin List File(s) used to create the average file(s), and 3) the name of a new file to create which will contain the corrected data.

We’ll start with and example of a command file. Suppose that we have an average file called oddball1.avg which has target events in bin 1, corresponding response events in bin 2, and was originally created with a log file called oddball1.log and a bin list file called oddball1.blf. We want to create a file corrected for overlap called oddball1.ove. The command file would look like this (by the way, tabs are optional, but sometimes helpful):

outfile oddball1.ove

avgfile oddball1.avg
bins 1 2
logdata oddball1.log oddball1.blf

The command file format has 4 keywords:

The file to be created with corrected data
ERP average file where data resides
Bin numbers in average file containing datat with overlap contamination
Log and Bin List File(s) used to create average file

The sum of all this information (outfile, avgfile, bins, and logdata) is called a "processing group", and you can specify many processing groups in the same command file. You can also have more than one avgfile and its associated bins and logdata in a particular processing group. Furthermore, each avgfile can have several associated bins and logdata. For example, it could be the case that we recorded our oddball data in 2 sessions, and have resulting log and binfiles called oddball1a.log, oddball1a.blf, oddball1b.log, and oddball1b.blf. Further, it could be the case that we have data in bins 1 and 2 that overlap, and that data in bin 2 also overlaps with data in bin 3. To handle all that, we would modify our command file to look like:

outfile oddball1.ove
avgfile oddball1.avg
bins 1 2 3
logdata oddball1a.log oddball1a.blf oddball1b.log oddball1b.blf

The overlap correction algorithm operates on one processing group at a time. The more data there is in a processing group the longer it takes to process that data. For that reason you should only put data that is thought to have overlap together in one processing group. For example, you may have an average file where data in bins 1 and 2 overlap, and data in bins 3 and 4 overlap, but where there is no interaction between the two groups. While the program would allow you to put all 4 bins into one processing group, it would take much longer to run than if you put each of the 2 bins into separate processing groups. Note that the outfile parameter can be the same for more than one processing group. When 2 or more processing groups have the same outfile, the corrected data from the later part of the command file is simply appended to the data from the earlier part of the command file. A command file for this example of 4 bins separated into 2 processing groups would like like this:

outfile oddball1.ove
avgfile oddball1.avg
bins 1 2
logdata oddball1a.log oddball1a.blf oddball1b.log oddball1b.blf
outfile oddball1.ove
avgfile oddball1.avg
bins 3 4
logdata oddball1a.log oddball1a.blf oddball1b.log oddball1b.blf

Output File Format

The output file specified by the outfile parameter in the overlap command file is a standard ERP data file (average file). It contains 5 bins for every bin that was corrected. These bins consist of (in the following order):
Original Average
the original average data before correction.
Corrected Average
the original data with overlap data subtracted out.
the overlapping waveform that is subtracted from the original data in order to correct it.
DC Response
the DC Response data from the overlap correction algorithm.
the predicted data from the overlap correction algorithm.

The bin descriptors for these bins consists of the original bin descriptor prepended with the string "ORIG:" (for original data), "CORR:" (for corrected data), "OVLAP:" (for the overlap data), "DCRSP:" (for the DC Response), and "PRED:" (for the predicted data).

Command Line Options

The command line options are as follows:
-s starttime
specify your estimate of the starting time of the time window for the Evoked Potential.
-e endtime
specify your estimate of the ending time of the time window for the Evoked Potential. The algorithm assumes that the "real" wave is zero outside this window.
-r regularization
specify a "regularization" parameter that affects the exactness of the solution. A regularization value of 0.01 would be "good". A value of 0.0 would be "perfect". The default value is 0.0100001.


Self-explanatory diagnostic error messages describe errors encountered in the command file.


Anders Dale
Ron Ohst


None yet known

Table of Contents