julfou81
commented
3 years ago Hi again,
I went on trying to understand what is going on and I believe that there is a weird interaction between the SBref volume taken as the reference for the realignment for the bold run and the cost function used in mcflirt.
For information, the TR we used is 1.1s and the contrast in the SBref image is much stronger that for the volumes in the bold run. This is expected and that is why the SBref volume is used to realign the bold space to the anatomical space usually with some boundary based registration.
But for mcflirt, there may be an issue and the difference of contrast between the SBref volume and a bold volume is not the same as the difference of contrast between two bold volumes from the same run.
Here is the SBref volume:
and the first volume of the corresponding run:
To illustrate my point, here is an observation: the plot of the second column of the .par file, output by mcflirt, with three different execution related to the same bold run:
- the reference is the 1st volume of the run (blue curve)
- the reference is SBref and the cost function is the default, i.e. normcorr (green curve)
- the reference is SBref and the cost function is mutual info (red curve)
=> there is something fishy with mcflirt, SBref and the cost function normcorr ! I never noticed that before even though we used fmriprep for many projects and subjects, maybe it is especially problematic with subjects with extremely low movements? I will also ask the FSL forum about this point as it is an issue not specific to fmriprep but rather to FSL-mcflirt. Also since this approach SBref - mcflirt is also used by the HCP, I will dig in that discussion to see if that was observed already.
effigies
yenwchen
toomanycats
What version of fMRIPrep are you using?
FMRIPREP v 20.2.1
What kind of installation are you using? Containers (Singularity, Docker), or "bare-metal"?
Singularity installation (version 2.6.1-dist), running on a high performance computing cluster.
What is the exact command-line you used?
Have you checked that your inputs are BIDS valid?
yes the input passes the bids-validator
Did fMRIPrep generate the visual report for this particular subject? If yes, could you share it?
Yes the visual report was generated, no error reported, it is under the dropbox link at the end of this post.
Can you find some traces of the error reported in the visual report (at the bottom) or in crashfiles?
no error reported
Are you reusing previously computed results (e.g., FreeSurfer, Anatomical derivatives, work directory of previous run)?
No
fMRIPrep log
If you have access to the output logged by fMRIPrep, please make sure to attach it as a text file to this issue.
We observed this strange output while building the GLM with nuisance regressors and noting that the columns with zeros where correlated with each other.
output: HTML reports, output and confounds_timeseries.tsv files under the following link: https://www.dropbox.com/sh/3e455qbh8anqwl3/AAACn2-tnmRBhXx44M_vO0qEa?dl=0
Here is for example the content of the .par file output of mcflirt run by fmriprep: the zeros are very strange and it is a very different result from what I obtain if I use SPM for realigning the same run (but realignment is to the first scan instead to the sbref as it is set with fmriprep) No zeros are found with SPM. EDIT: I just check with my local FSL installation and I found that mcflirt is giving the same output as fmriprep! Thus it is not seem to be a problem with fmriprep, rather a strange behaviour of mcflirt! This subject had very low movements. Thank you for sharing your thoughts!
Here is a plot (made with FSLeyes) of the translation along x, calculated with mcflirt (.par file, 4th column, ref= sbref) and with spm (rp file, 1st column, ref=1st scan): Quite different!
Another example: same run, looking at the ortation around y, calculated with mcflirt (.par file, 2nd column, ref= sbref) and with spm (rp file, 5th column, ref=1st scan):
