Event files

The primer for most, if not all fMRI analysis is the generation of the event file. The event file (also known as the onset file) is a file which contains the timings and other relevant information of the regressors you wish to model. If the event file was capable of talking, it would say “Hey GLM! These are the timings that these events happened, now use these timings to convolve the delta distribution of HRF as a regressor (either as a boxcar or an impulse) and find their corresponding beta estimates.” So, the event file is where you specify how you want to model your GLM. See this page for more information on HRF.

Event file format

The BIDS-compliant event file format minimally includes regressor names, onsets, durations. In BIDS specification, seperate fMRI runs are kept as seperate event files and are stored in the .tsv file format. However, in our lab, we use a wide array of event file formats (.mat, .csv, .xslx) which contains not one but all fMRI runs for that participant.

In our event file format, we keep the first column as the run number, the second column as the regressor name or regressor number, the third column as onset and the fourth column as the duration. The duration column specifies how you will convolve the HRF. In other words, it indicates whether you want your regressor to be modelled as an epoch, or as an impulse. You will be seeing examples of an event file down the line.

In our lab we use some terms interchangeably. While reading this text, you may run into these words used as a substitute. So to clarify, let us introduce some jargon:

  • You may see that some people call their event file as the “regressor file”. Hence, the events may be referred to as “regressors” or visa-versa in a specific context.
  • People may refer to regressors modelled with no duration as an “impulse” or an “event”.
  • People may refer to regressors modelled with a specified duration as an “epoch” or “a box car stimulus” or a “block”.

What’s an Impulse and what’s an epoch?

You may remember from your first level lectures that we use a canonical HRF to fit our (acquired) fMRI data. The event file is the part where each regressor’s timing is matched with the fMRI time series (imaging) data.

There are two ways to model a regressor. It can either be an “event” (some people call it an impulse) or an “epoch” (duration). When regressors are convolved as an impulse, only the given activity at that moment is used to convolve the HRF. When you convolve it as an epoch the beta values you have at hand are an average estimate of activity during the given time period (hence temporally more wide-spread).

So, you can model things as either a moment in the fMRI run (impulse), or as a sustained duration (epoch).

The decision to make your regressor an impulse or an epoch depends on the question you ask and the study you wish to conduct. There are use cases for both. An extended rest period would make more sense to be modelled as an epoch, whereas the presentation of a stimulus may be better to model as an impulse. There are no specific rules, and common logic applies.

To wrap up, let’s re-consider what we’ve discussed so far:

  • You can model a button press as an impulse (event) as it is momentary thing.
  • You can model the time the participant spent looking at a picture as an epoch.
  • You can model the time the participant started looking at a picture as an impulse

and so on…

Nuts and bolts of event files

If you wish to model your event as an impulse/event, then you will need to find the onset of your regressor. This information will be present in the behavioural data of the participant. This means the time the “event” started.

For example; the very moment a picture’s presentation started would be its onset. Whether you model your regressor as an event or an epoch, you will always need to find it’s onset. If you were to model it as an epoch, you would also need to specify the duration of the regressor.

If your participant saw a picture and performed a button press as a response, the moment the button press is performed would be the offset of the stimulus. In this example, you can model the duration of your epoch as the time that passed between the offset and the onset (or the reaction time).

For regressors that are modelled as impulses, the duration must be 0.

To model a regressor and place it on your event file, you will need to find it’s onset, and then assign a name or number to your regressor.

Each different type of event you wish to contrast for (ie. look for change in levels of activity) you will need to specify it as a regressor.

Below, you can see an example of an event file. In this experiment, there are 4 types of regressors. REST, BREAK, DEG, INT.

Each regressor has it’s session, name, onset and duration written. In this experiment, participants listened to INTact sounds and DEGraded sounds. There were also parts where they were explicitly asked to REST, or took a BREAK to move on to the next episode. Do notice how the onset of the first event (REST) is 0. This indicates that the time the fMRI run started and the very first event that has occurred after the scanner trigger was REST. Notice the onset of the upcoming BREAK regressor is almost same as the duration of the REST regressor. This indicates that these regressors occur one after another. If you keep looking at the event file in this fashion, ie. by looking at the duration at one row and then the onset at the next row, you will see the flow of the experiment (which events occurred at what time).

While looking you may notice some larger gaps between other regressors (such as between line 5 and 6). These may be unmodeled events, or blank intervals to decorrelate consecutive events.

Reflecting back on what you’ve learned so far, is there anything you think is missing in this event file?

Yes. There are no regressors modelled as impulses. This is normal as this design did require to have any (furthermore, this was a block design). However, if any of those regressors were modelled as impulses instead of epochs, their durations would be 0. As you can see below.

Good habits

One good practice is to model regressors of non-interest even if you are not concerned with them in your analysis, as they allow you to delineate activity particularly if your events occur in rapid succession. This will allow you to demarcate the borders of different events. For example, you can model incorrect responses as a regressor so that their activity does not get picked up by other events and/or be considered as the baseline. Do keep in mind that the more different types of regressors you have the less degrees of freedom you have. It is good practice to model your regressors of non-interest as a single type of regressor to combat this statistical problem. Details of this are discussed in the “Introduction to GLM” book at the main page.

Do note that although in these two examples the timing of the regressors are ordered (as in, the onset times are in ascending order) they need not be that way. SPM will re-arrange the onsets when you give them.

Here, you saw examples of modelling based on time. It is possible to do modelling on TR’s as well. Which would pertain to the image acquisition numbers instead of the timings. Just mentioning this as you may be confused if you read it elsewhere.

Be extremely cautious.

This part of analysis is the core of fMRI analysis. If anything you should give your all while generating event files because even one tiny mistake may lead to catastrophic outcomes. You may end up not getting any results, you may get completely weird results and interpret them as something novel only to find that you mis-labelled your regressors, or you did some other kind of mistake. In any case, CHECK YOUR EVENT FILES. Here’s a list of things you can check:

  • You can not model two different types of regressors to the same time frame or moment in time (impulse). Always check if your regressor’s duration or onset time clashes with another regressor’s or if your regressor time is occurring inside the time frame of another event.
  • Some experiment’s timings may reflect the time the experiment script started running and not the time the scanner started. In other words, there will be a delay between the time the experiment started, versus the time the scanner started running. When generating your event file this time difference needs to be subtracted from all onsets you use for modelling. Otherwise, your timings will be off. If you don’t understand what you read from this bullet point, ask anyone in our lab for a proper explanation.
  • Make sure you are getting enough repetitions (samples) for each of your events for all of your participants. If you see that your participant’s distribution of number of events is not sufficient, there may be a mistake in your event file code or worse, your experiment.
  • Make sure your events are distributed well across the fMRI run. This means that specific event’s onsets should occur throughout the session and not just at the beginning or the end. Ideally, the average onset of your events should regress to half of the duration of the fMRI run (although this may not always be possible).