issue with mcflirt using SBref as reference when subject doesn't move #205
Comments
|
If there is minimal movement along an axis or rotation, no movement is slightly favored in some situations due to interpolation effects. |
|
Thank you for the quick answer! However I am puzzled by the different results of mcflirt depending on the cost function used or reference volume used. Anyway I am sure that it doesn't change the result for the realigned run. My concern is more if I want to use the motion parameters as nuisance regressors in the GLM, is it ok to use a column of zeros in the GLM? SPM seems to flag those as having spurious correlation with other constant regressors. |
|
This is really an FSL/MCFLIRT issue. @gcburgess may have an additional comment, as I believe he interacted with Oxford on this issue. (Yes, we have observed it previously). If you have an entire column of zeros, then yes, that could in theory cause problems with certain tools, depending on whether they are built to work with rank-deficient matrices. |
|
Thank you Mike! I will continue to look for a solution and perhaps eventually contribute to a PR in FMRIPREP to tackle this issue. I will keep you posted. |
|
I looked back at some emails with Steve, MJ, and Jesper and this was the effective conclusion:
and
So, that could explain why different reference images and different cost functions give different (non-zero) solutions. |
|
Thank you all for your insights! I sent some data to the the FSL team, they were able to reproduce the observations we made and they are working to understand what is going on internally. Sometimes the effect of the zeros is relatively important, the FD_mean of one run calculated by mcflirt my appear to be as low as 0.013 mm while calculated with other tools such as AFNI or SPM, the FD_mean is actually about 0.11mm. I will keep you posted if I learn anything new. |
|
Yes. Please post back if you learn anything else. This issue isn’t new to them as we’ve raised it previously, although perhaps they currently have the bandwidth to look into it in greater detail.
…--
Michael Harms, Ph.D.
-----------------------------------------------------------
Associate Professor of Psychiatry
Washington University School of Medicine
Department of Psychiatry, Box 8134
660 South Euclid Ave. Tel: 314-747-6173
St. Louis, MO 63110 Email: mharms@wustl.edu
From: julfou81 <notifications@github.com>
Reply-To: Washington-University/HCPpipelines <reply@reply.github.com>
Date: Wednesday, February 10, 2021 at 4:07 PM
To: Washington-University/HCPpipelines <HCPpipelines@noreply.github.com>
Cc: "Harms, Michael" <mharms@wustl.edu>, Comment <comment@noreply.github.com>
Subject: Re: [Washington-University/HCPpipelines] issue with mcflirt using SBref as reference when subject doesn't move (#205)
* External Email - Caution *
Thank you all for your insights! I sent some data to the the FSL team, they were able to reproduce the observations we made and they are working to understand what is going on internally. Sometimes the effect of the zeros is relatively important, the FD_mean of one run calculated by mcflirt my appear to be as low as 0.013 mm while calculated with other tools such as AFNI or SPM, the FD_mean is actually about 0.11mm. I will keep you posted if I learn anything new.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub<#205 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AA5TABVDFWL5KEZIDFH2DRTS6L7STANCNFSM4WQ5OGAQ>.
________________________________
The materials in this message are private and may contain Protected Healthcare Information or other information of a sensitive nature. If you are not the intended recipient, be advised that any unauthorized use, disclosure, copying or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this email in error, please immediately notify the sender via telephone or return mail.
|
|
Hello experts, thank you for this intriguing discussion. We use the data from HCP-Aging (2.0 Release) and observe that the motion regressors from some subjects (say "some" is very conservative actually... we ran 12 subjects so far and more than half of the 12 subjects have at least one resting functional run that shows zeros in one or more motion directions). I found that this issue is also reported on the fMRIPrep github discussion (thank you @julfou81 !!). From my understanding, the alternatives include (with the sbref as the reference) We are currently at the stage of deciding whether to use the HCP-Aging minimally preprocessed data or to run the preprocessing on our own (either with HCPpipeline or fMRIPrep), therefore, we are comparing the outputs from two pipelines. The zeros in motion regressors appear mostly in low-motion runs from both HCP minimally preprocessed regressor (Movement_Regressors.txt) and fMRIPrep confounds output, like the above discussion. I am wondering what is the approach that you would recommend to proceed with this issue? Any opinions or suggestions will be very helpful! Thank you. |
|
What is the problem you are trying to solve here? Motion regression is not beneficial over doing sICA+FIX as was already done on these data. Reprocessing the data would be a lot of work for likely inferior results. |
|
The preprocessed and denoised data is no doubt valuable and will save us a lot of work. It's just that I have not come across the data with motion regressors looking like that (with a lot of zeros) and I am curious about the reason of causing this. This discussion talks exactly it and I am wondering what's people's opinion. Would that affect the motion correction (in the preprocessing) and the subsequent spatial ICA? |
|
These subjects don't have much motion and there is a little bit of an activation energy to say there is a tiny movement. There will not be any downstream issues from this for recommended processing. |
Hi, I am not exactely a HCPPipelines user but rather a FMRIPREP user but I noticed an issue with a methodology that I was derived from the one used by the HCP pipeline, so I thought I might as well post my question here:
For a subject with low movements (FDmean < 0.1mm for TR=1.1s) I noticed that the .par file output from mcflirt used by FMRIPREP was filled with many zeros, which is strange:
Looking further, I was able to reproduce this output by running mcflirt on that specific run using SBref as a reference for the realignment.
I then tried two things:
-re-run mcflirt using the first volume of the run as reference
-re-run mcflirt using SBref as reference, but this time using another cost function: mutual info instead of the mcflirt default which is normcorr.
Here is the result, illustrated by plotting the second column of the .par file for these 3 runs of mcflirt:
Is it something that has been observed before? Looking at the HCPpipelines code and mcflirt.sh in particular, it looks like SBref is not used directly as the reference for mcflirt (but rather the Mean of volumes 11-20) and thus a similar behavior may not happen with HCPPipeline...
The text was updated successfully, but these errors were encountered: