Getting started with 4D-neuroimaging/bti data

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:

1. hs_file, containing a list of coordinates in 3D-space, describing the participant's headshape.
2. config, containing system specific information regarding the acquisition parameters etc
3. one or more data files, the name(s) of which depend on the acquisition parameters used (see below)

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 fieldtripdefs function, which sets the defaults and configures up the minimal required path settings (see the faq):

addpath <full_path_to_fieldtrip>
fieldtripdefs

Data files are called something like:

1. c,rfDC
2. e,rfhp1.0Hz
3. hc,rfDC
4. 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 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')

1. The order of the channels as they appear in the data file is not nicely ordered compared to how the channels are arranged on the helmet. This should not be a problem because FieldTrip works with the channel labels and does not make assumptions on a particular ordering of the channels. Yet, it is important to keep in mind that at some places in the code there is no explicit check on the matching of the channel order. This can for example be problematic when using precomputed leadfields for inverse modelling. Leadfields can be computed by ft_prepare_leadfield, where you can provide a list of channels for which the leadfield has to be computed. The order (and number) of the channels specified in this list has to be the same as the order and number of channels in the data you are later going to use for your inverse modelling.
2. Typically, before each recording, you have to specify a set of analog and digital weights which will be applied to the data before they are stored on disk. This means that the data as they are stored on disk represent so-called 'synthetic gradients' rather than the magnetic field (or gradient) picked up at a particular coil (pair of coils) location. Namely, the data on each channel is the magnetic field picked up by the coil corresponding to that channel minus a linear combination of the fields picked up by a set of reference coils. This linear combination is different for each channel and is specified by a weight table. The analog weights are applied prior to digitization, and therefore cannot be 'undone'. The digital weights can be 'undone', or one can recompute the weights using a different set of reference channels, or a different stretch of data. Importantly, since the data usually essentially consist of synthetic gradient data, the digital weight table should be incorporated into the gradiometer-structure's balancing matrix, for a correct computation of the forward model. As of yet, this only works for data acquired with the Magnes 3600 system (and is tested with the Glaswegian 248-magnetometer system). Application of the balancing for 148-channel systems is still disabled, because the header information is not explicit with respect to the channel order of the digital weights.