Hello all!
I would like to know if the preprocessing steps of fMRI images are performed to the original functional images inevery step or to the newly created from the last preprocessing step.I suppose the second is true and the order of the steps is crucial.For example after realignment,slice timing, coregistration are performed rar files are created…Is that right?I am wondering if the slice timing must be performed after realignment or before.Another question is for coregister.Why the ‘‘other images’’ are optional?I supposed that not only the means image and the anatomical but also all the functional must be coregistered.Last, could anyone list the prefix of a file having completed all the preprocessing steps?Thanks in advance!
Hi Jenny,
You should be able to find answers to all your questions at http://fmriprep.readthedocs.io/en/latest/workflows.html and http://fmriprep.readthedocs.io/en/latest/outputs.html.
From your use of prefixes, I suspect you’re using SPM as your preprocessing pipeline? Just so you know, fmriprep (the tag on this post) is a separate preprocessing pipeline (see Chris’s links). I have very little experience with SPM, and it has been many years, so assuming that is what you’re using, I can’t help with the specifics of the tool. However, I can make a couple comments:
I’m not entirely clear on what all SPM does; it should not modify the original files, but it does change them in some way (probably an updated header, but I haven’t actually looked into this). But yes, the new files should be the preprocessed variants.
I am wondering if the slice timing must be performed after realignment or before.
Slice timing correction, if performed, should be performed before coregistration. Once you interpolate your image, the slice information is at least partially lost, and the assumptions of any slice-timing correction algorithm will be violated.
Related: Obtaining movement estimates before slice time correction
Thank you but I m using SPM…
You are right …Slice time correction should certainly be performed before coregistration but I m wondering if slice timing algorithm is violated if performed after realignment…It seems there is a dichognomyon this issue…
Oh I see - I was misled by the tag you originally used (fmriprep). I changed it to SPM for clarity.
What does “realignment” mean in SPM? Head-motion correction? If so, the argument put forward in the above link says “calculate the motion parameters, run STC, and then apply motion correction”.
This makes sense to me, as head-motion correction is actually a coregistration of all volumes to some reference volume, so it would violate the assumptions of STC algorithms, strictly construed. One can argue that, if motion is small enough, it may not be catastrophic, but at least our group has followed the advice of Power et al, 2017.
The order of operations in SPM is entirely user selectable and in most cases, so is how transformations are applied.
For example, in coregistration, the “other images” is there so that you can use the Mean image (typically output by Realign) as the registration driver (it is used to estimate coregistration parameters) but keep all the other images in register. In other words, you estimate the coregistration parameters, but save them so they can applied to all the other images.
In the SPM batch system, this would look like:
Realign and Reslice: Option: Reslice mean images only
Coregister Estimate: Use Mean image to estimate, in other images use a dependency and point at the Realigned Images Estimate.
This way the realignment and coregistration are performed all at once, rather than in two steps.
The prefixes for SPM output vary on the basis of user selection. In general they are:
a - slice timing correction
r - resliced (this can be from coregistration or realignment)
u - undistorted, (from Realign unwarp - which requires reslicing)
w - warped - typically this is done by normilization
s - smoothed
c - a tissue class created by segment (c1 is Gray matter, for example, mostly for anatomy)
So an entirely plausible fully preprocessed file, epi2d_task.nii might be:
swauepi2d_task.nii
or swep2d_task.nii
Note that the r is not present, as when SPM combines all transforms into one step (realignment estimation, coregistration estimation and normilization to MNI space), which omits the r.
An example batch, produced by SPM, can be found in the SPM install folder. You can open in the batch system by navigating to the SPM install directory/batches/ and loading preproc_fmri.m
Note, this will show an SPM default batch, but I would change some things, such as the normalise write voxel size (from [2 2 2] to something closer to your funciontional data) for example. The fully preprocessed data from the SPM default batch, with slice timing before motion correction would be:
swuaep2d_task.nii.
For a great resource on SPM, see here: https://www.fil.ion.ucl.ac.uk/mfd/Schedule/Schedule.html
2 Likes
Is unwrapping necessary?I dont see it a lot in the tutorials?And if yes I choose realign estimate only and the reslicement takes place in the stage of un wrapping?
It is impossible to say if it is necessary, but it is the SPM default. I personally don’t use it unless I have a fieldmap, because then I want to correct for distortion in the epi image. So, when I don’t have a fieldmap, I use Realign Estimate and Reslice, and only reslice the Mean image. Then that mean image and the estimated realigned images are used in coreg. If you do that, and pass the coregistration estimates into Normilzation then SPN will combine everything and reslice at that point (at normilization).
I do not have any strong opinions on slice timing (at this time).
In SPM, I am not sure how I would estimate motion parameters, perform slice time correction, and then apply motion parameters. It may be possible to do this by passing the Realign (estimated) images into Slice Time Correction but I really don’t know, sorry. If motion is relatively small, then performing slice time correction first, then using those images as the input into realign would be easy enough.
2 Likes
Is it wrong to create files with the prefix ‘‘swaur’’?I run realign estimate and reslice all images and then realign and unwrap with all the images resliced (unwarp)…
The prefix “swar” (realignment + slice-timing corretion + normalization + smoothing) or the prefix “swau” (realign&unwarp + slice-timing correction + normalization + smoothing) are both more common, and I believe also more correct. I do not believe realign&unwarp should be run after realignment. The reason is not only because it is redundant (realign&unwarp will also realign and reslice your data), but also because realign&unwarp is going to try to estimate and correct potential motion-by-suceptibility interactions (i.e. changes in the observed “shape” of the brain associated with subject-motion within a inhomogeneous field) and in order to do that it needs to estimate the derivative of the field with respect of motion parameters, so it needs to be able to actually “observe” the original subject motion (which it will not be able to do if you apply realignment first).
Hope this helps
Alfonso
Thank you for your helpful explanation!