This page explains how to get started reading and using each of these file types in FieldTrip.
MEG datasets obtained from a 4D-neuroimaging MEG-system are usually stored in a directory structure which looks like this:
/basepath/subjid/scanname/sessionname/runname/
Within each runname/-directory is a bunch of files which do not have uniquely identifiable names, this is important to keep in mind when a given dataset consists of multiple runs per subject, or when you analyse multiple subjects. Each runname/-directory usually contains the following files:
FieldTrip knows how to deal with raw, i.e. unprocessed, data files. Data files which have been obtained using 4D-software (such as averaging, digital weight computation etc) can probably not be handled by FieldTrip.
To get started, you should add the FieldTrip main directory to your path, and execute the ft_defaults function, which sets the defaults and configures up the minimal required path settings (see the faq):
addpath <full_path_to_fieldtrip> ft_defaults
The 4D software organizes all files in a nested directory structure, managing the subject, scan/experiment, session and run, with at the lowest level the actual data files. The files containing the various bits of information do not have file extensions to distinguish them, the full filename instead is required to interpret which file is which. A 4D dataset directory at the lowest level (a “run”) might contain something like this
| filename | content of the file |
|---|---|
| 0 | EEG/MEG recording (channel X time data) |
| 1 | MEG short recording to determine head position |
| 2 | MEG short recording to determine head position |
| config | system specification and acquisition parameters |
| exp0 | redundant information about the experiment |
| exp1 | redundant information about the experiment |
| exp2 | redundant information about the experiment |
| hs_file | digitized head-shape coordinates (x-, y-, z-points) |
| pdf.txt | ascii file with a description of the alternative file names of the data (see below) |
Depending on how the dataset is exported the actual data files are just named 0, 1, 2, …, (as above) but could also be called something like:
| c,rfDC |
| e,rfhp1.0Hz |
| hc,rfDC |
| e,rfhp1.0Hz,COH |
The letter(s) before the first comma refer to the recording mode: e for epoched data, c for continuously recorded data, or hc for continuously recorded data with the coils in continuous headmotiontracking mode. The rfXXXX part refers to the hardware filter settings, rfDC meaning no filtering at all, and rfhp1.0Hz means that a 1.0 Hz cutoff high pass filter was applied prior to the digitization of the data. COH (or COH1) refer to the short recording to obtain the positions of the Coils On Head.
The 4D software also uses a directory structure to organize the data in line with its patient/subject database. The directory structure looks like
p0/s0/n0/r0 p0/s1/n0/r0 p0/s2/n0/r0 p0/s2/n0/r1 p0/s2/n0/r2 p0/s2/n0/r3 p0/s3/n0/r0 p0/s4/n0/r0 p0/s4/n0/r1
where the numbers (here 0, 1, 2, …) can be different.
| directory level | explanation |
|---|---|
| pN | subject level |
| sN | scan level, this usually corresponds to the experimental protocol |
| nN | session level, this usually is identified by the date and time |
| rN | run level |
The ft_read_header function reads header information and represents it in a common data-independent format. It takes the name of the data file as input. Header information with respect to a particular data file is stored in two places: the run-specific config-file, and the data file itself. The low level reading function read_4d_hdr reads the header information from the specified data file and then tries to read the corresponding config file which should be stored in the same directory.
To read the header from one of your datasets, use
hdr = ft_read_header('c,rfDC')
when your current directory is where the data can be seen, or
hdr = ft_read_header('/basepath/subjid/scanname/sessionname/runname/c,rfDC')
Typically, a set of (analog and a set of) digital balancing weights are applied to the data upon acquisition. The digital balancing weights are present in the header information (this is the case for 248-channel systems; we are still working out how to do this for the older 148-channel systems). This information is stored in the field hdr.grad. The tra-matrix (grad.tra) represents in each row the linear combination of measurement coils contributing to the corresponding channel. The coils are defined to have a position and an orientation (grad.pnt and grad.ori), and the channels are identified through the label (grad.label). The rightmost part of the tra-matrix usually contains the balancing coefficients. As a whole, the tra-matrix contains crucial information that is needed for the correct computation of the leadfields, which are used for forward and inverse modelling.
The 4D neuroimaging software contains functionality to compute and apply a set of balancing weights, based on the magnetic field measurements by a set of reference coils, located far away from the brain. The idea is that these coils mainly pick up environmental noise. By subtracting a weighted combination of the reference coil measurements from the coils that pick up the brain activity, one potentially achieves a reduction in the noise (this is typically low frequency noise, so it is most relevant when analysing event related fields). The set of weights can be computed using linear regression. The command-line programs provide by 4D are called 'cfw' and 'afw', and operate on a whole data set at once. FieldTrip contains an implementation of the same algorithm, which moreover allows for more flexibility than the 4D implementation. For example, one can use a subset of the data for the weight computation, and/or preprocess the reference coil data (amplifying particular features) prior to weight computation. The FieldTrip function that achieves the weight computation/balancing is ft_denoise_pca