Why and how of slice timing correction
When acquiring a BOLD time series, each frame in a time series usually consists of a brain volume acquired slice by slice within a time span of a single TR. The TR can vary significantly depending on a number of factors, including in-plane resolution, number of slices, and in-plane acceleration options, such as GRAPPA and SENSE, and multiband acquisition, where multiple slices are acquired simultaneously.
Since the slices are recorded at different times, the signals in the different slices correspond to different points in time. This can lead to temporal discrepancies in the data that can affect the results of both activation and functional connectivity analyses. For example, while an assumed HRF model may correctly describe the expected signal amplitude for the slice acquired in the middle of the volume acquisition, it may lag behind the signal acquired in the first slices and precede the signal acquired in the last slices. Although the evolution of the BOLD signal is rather slow, these differences can still be quite pronounced for slow repetition times (TR), which can take between 2 and 3 seconds, while they may be less important for sequences that take 1 second or less to acquire a full brain image.
One way to deal with differences in the times of the slice acquisitions is to time shift the acquired signal and align all slices to the same time, usually to the time in the middle of an acquisition of a frame. A number of different algorithms have been developed for this purpose, and most fMRI analysis packages provide the ability for slice timing correction. However, it should be noted that slice timing correction is a form of interpolation that may not be entirely accurate and can introduce artifacts into the data. A general guideline, most commonly found in the literature, is that slice timing correction does not provide much benefit for TR < 1 s, while the effect can be quite pronounced for TR ≥ 2 s.
Another dilemma is the question in which step the slice timing correction should be performed. Since motion perpendicular to the slice plane can affect the effective timing of slice acquisition, the dilemma arises as to whether slice timing correction should be performed before or after the motion correction step. Various authors seem to agree that it would be best to perform slice timing and motion correction in a single step, but no such tools currently exist. Although opinions differ, for small motions it seems better to perform the slice timing correction before the motion correction.
Implementation of slice timing correction in QuNex
In QuNex, the slice timing correction is implemented as part of the fMRIVolume HCP minimal preprocessing step. It uses FSL's
slicetimer and is performed immediately before motion correction
A number of bold acquisition information, parameters and settings are relevant when performing slice timing correction.
Slice timing information
When considering the use of slice timing correction, it is important to know how the slices were acquired. For legacy data acquired without multi-slice acquisition, the slices are usually acquired from bottom to top in an interleaved fashion. If we number the slices from 1 to N, starting with the lowest slice, the acquisition would start with slices 1, 3, 5, 7, ... , and continue with 2, 4, 6, 8. While this is the most common acquisition strategy, it is not the only one. The slices may also be acquired non-interleaved and/or in the top-to-bottom instead of bottom-to-top order. Before considering the use of slice timing correction, make sure you know the order in which the slices were acquired.
Custom slice timing files
One way to precisely specify the slice timing correction is to consider the actual slice timing information. This is especially important if a non-custom slice acquisition order was used or if data was acquired with multi-slice acceleration.
If the data you are working with has been provided to you in BIDS format, each bold image should have a corresponding json sidecar file that may contain slice timing information. Similarly, if you have onboarded DICOM data and the DICOM files contain the appropriate information,
dcm2niix has prepared json sidecar files that are stored with the NIfTI files in the
nii folder and contain slice timing information. Please note that while
dcm2niix is usually able to extract slice timing information from Siemens DICOM files, it may not be able to do so for DICOM files from Philips or other vendors. Therefore, check whether the json sidecar files contain the relevant information.
If you have json sidecar files with slice timing information, QuNex provides specific functionality for preparing and using custom slice timing correction files. The basic command for preparing custom slice timing correction files is
prepare_slice_timing. The command takes two parameters,
slicetimingfile. The first parameter is the path to the json sidecar file that contains the slice timing information, and the second parameter is the path to the custom slice timing file to be generated. The command checks the json file for information about TR, slice acquisition order, and slice timing. It then prepares a custom slice timing file that can be used with FSL's
slicetimer. Each line contains a fraction of the TR by which the slice timing should be shifted either forward (positive fraction) or backward (negative fraction) in time. The function calculates the fractions so that the slices will be aligned in time to the center of the TR. For example, if TR was 2 seconds long, all slices in the first BOLD frame will be aligned to 1 s after the start of BOLD, all slices in the second BOLD frame will be aligned to 3 s after the start of the BOLD sequence, and so on.
QuNex also provides the ability to automatically create custom slice timing files for all BOLD data as part of the
setup_hcp command. To use this feature, first verify that the BOLD json sidecar files contain the relevant information. Then set the optional
slice_timing_info parameter of
setup_hcp to 'yes'. In this case,
setup_hcp automatically calls
prepare_slice_timing for all BOLD files that have been set up for HCP processing. In particular, for each BOLD file, a corresponding slice timing file is saved in the same folder and under the same name as the BOLD file, with the tail
Legacy Style Data Mode
Because HCP style data rely on high spatial and temporal resolution of TR ≤ 1 s, HCP pipelines were initially developed without slice timing correction. Though the slice timing correction option was introduced later to support processing of legacy data with longer TR, the option is available only when legacy-style data processing mode is enabled. To achieve this, set the
hcp_processing_mode parameter to 'LegacyStyleData' when running the
hcp_fmri_volume command. This can be set either in the
batch.txt file or directly when calling the command from the command line.
To perform slice timing correction when executing the
hcp_fmri_volume step, use the following three parameters, which can also be set either in the
batch.txt file or on the command line. First, set the
hcp_bold_doslicetime parameter to 'TRUE'. This tells
hcp_fmri_volume to conduct slice timing correction as the first processing step immediately before the motion correction.
Second, if you have used QuNex functionality to prepare custom slice timing files, or if you have created them yourself, named them, and put them in the right place, then you can set the
hcp_bold_slicetimingfile to 'TRUE'. In this case QuNex will pass the custom slice timing files to
slicetimer to perform the slice timing correction.
Third, if you have not prepared custom timing files for each BOLD file, you must prepare the proper parameters to pass to
slicetimer using the
hcp_bold_slicetimerparams QuNex parameter. To maximize the flexibility of
slicetimer usage, the
hcp_bold_slicetimerparams parameter is designed as a pass-through parameter. In particular, the parameter should contain a comma- or pipe-separated list of parameters, exactly as they are to be passed to FSL's
slicetimer. To prepare the
hcp_bold_slicetimerparams parameter, consider the
slicetimer interface, specifically the optional parameters:
Usage: slicetimer -i <timeseries> [-o <corrected_timeseries>] [options] Compulsory arguments (You MUST set one or more of): -i,--in filename of input timeseries Optional arguments (You may optionally specify one or more of): -o,--out filename of output timeseries -h,--help display this message -v,--verbose switch on diagnostic messages --down reverse slice indexing (default is: slices were acquired bottom-up) -r,--repeat Specify TR of data - default is 3s -d,--direction direction of slice acquisition (x=1,y=2,z=3) - default is z --odd use interleaved acquisition --tcustom filename of single-column slice timings, in fractions of TR, +ve values shift slices forwards in time. --tglobal global shift in fraction of TR, (default is 0) --ocustom filename of single-column custom interleave order file (first slice is referred to as 1 not 0)
The HCP fMRI Volume code automatically prepares and passes the
-r parameters. If
hcp_bold_slicetimingfile is set to 'TRUE', QuNex prepares the correct
--tcustom parameter. The rest of the parameters must be set by the user. For example, if the data was acquired in reverse slice order (top to bottom) in an interleaved fashion,
hcp_bold_slicetimerparams should be set to
Similarly, if you have prepared a custom oder file, the
hcp_bold_slicetimerparams parameter should be set to
--ocustom=<path to custom order file>, e.g.,
--ocustom=/my_study/sessions/specs/slicetimer_oder.txt. The custom order file must be a text file where each line specifies the order in which each slice was acquired. For example:
1 56 2 55 3 54 ...
would specify a sequence in which the bottom-most slice was acquired first, then the third, the fifth, and so on to the top, and then the remaining slices were acquired back from top to bottom.
In the same manner, if all the BOLD files were acquired using the same slice timing, you could prepare a single custom slice timing file and pass it on to
slicetimer by setting the
hcp_bold_slicetimerparams parameter to
--tcustom=<path to custom slice timing file>, e.g.,
Especially for long repetition times (TR), a valid slice timing correction can significantly improve the analysis of BOLD data. To enable this, QuNex uses FSL's
slicetimer as the first BOLD processing step immediately before motion correction, and provides additional features and options for processing slice timing information and passing the correct parameters to the
Each of the options has its advantages. If the study combines BOLD files with different slice timing order within or between sessions, the most robust option is to ensure that the correct slice timing information is present in the json sidecar files and use the QuNex functionality to prepare and use the custom slice timing files.
If all BOLD files use the same sequence with the same slice timing for all sessions in the study, the easiest way is to create a single custom order or custom slice timing file and pass it with the
If all BOLD files used the standard bottom-up interleaved or non-interleaved sequence of slice acquisition, the simplest option is to provide this information by setting the '
hcp_bold_slicetimerparams' parameter to '
--odd' and/or '
In any case, check your sequence information carefully so that the slice timing correction runs correctly.