glasserm
commented
3 years ago If there is minimal movement along an axis or rotation, no movement is slightly favored in some situations due to interpolation effects.
Open julfou81 opened 3 years ago
glasserm
commented
3 years ago If there is minimal movement along an axis or rotation, no movement is slightly favored in some situations due to interpolation effects.
julfou81
commented
3 years ago 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.
mharms
commented
3 years ago 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.
julfou81
commented
3 years ago 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.
gcburgess
commented
3 years ago I looked back at some emails with Steve, MJ, and Jesper and this was the effective conclusion:
when true motion is very low there is a strong cost function bias towards exactly zero estimated motion - but that doesn't mean that that factor will always dominate to give exactly zero estimation - aspects in the image could still pull you away from that.
and
due to nonlinearities in the cost function, one frame with say a 0.01 mm true translation might get detected as such, while in another frame that same translation might get reported to be zero (due to how it interacts with the other translations and rotations)
So, that could explain why different reference images and different cost functions give different (non-zero) solutions.
julfou81
commented
3 years ago 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.
mharms
commented
3 years ago 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.
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)
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 GitHubhttps://github.com/Washington-University/HCPpipelines/issues/205#issuecomment-777068048, or unsubscribehttps://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.
yenwchen
commented
2 years ago 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) (1) use "mutual information" cost function (FSL mcflirt) (2) use AFNI 3dvolreg instead
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.
glasserm
commented
2 years ago 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.
yenwchen
commented
2 years ago 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?
glasserm
commented
2 years ago 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...