Mark,
Thank for your response. Based upon your comments I did some more investigation and found that the source of the problem. It is definitely distortion correction. This was determined by running our same preprocessing pipeline (mcflirt, dc, and bbr) with each step turned off one by one. The distortion correction is working fine except for edge slice. Our study did not acquire the whole brain and cut off a portion of the cerebellum. When you play a move of the edge slice you can see the signal intensity change with motion. For some data sets the signal intensity increases/decreases dramatically ( absolute change greater than 15000) as it approaches the reference slice. We have intensity normalization on. This then spreads this large signal intensity change across the entire brain. After normalization the range of signal intensity is less than 40 with the large variability near the reference. This has a dramatic affect on the fsl_motion_outliers.
I think the source of the problem is that we did not acquire the entire brain. I don’t think this change will be a problem since it is a global change and we will be regressing out the CSF and WM signal before processing our data. I am rerunning the data now without normalization. I can always normalize the data as the last step in the post processing.
Thanks again for your thoughtful reply,
Bob
On May 2, 2016, at 3:54 AM, Mark Jenkinson <[log in to unmask]<mailto:[log in to unmask]>> wrote:
Hi,
This is really unusual and I've not come across this before.
There is nothing obvious in the motion correction, distortion correction or boundary based registration that would change the global signal intensity. If there is a change then the behaviour of fsl_motion_outliers is as expected, since the dvars metric is just measuring the intensity difference and is sensitive to any points in time where the intensity difference is unusual (i.e. an outlier).
Are you using temporal filtering in your pre-processing? I notice that your input is "filtered_func_data" in the last case, and if you had done temporal filtering then I think this might potentially explain the situation as it would allow some artefacts to influence nearby timepoints.
Also, do you have a lot of distortion?
It isn't obvious how distortion correction would mainly affect signals near the reference image, but it is more likely to change the global signal than motion correction or registration would. So it would be worth knowing about that.
Sorry I don't have any clear answers for you at this stage.
Hopefully some of the answers above will help us figure out what is going on.
All the best,
Mark
From: FSL - FMRIB's Software Library <[log in to unmask]<mailto:[log in to unmask]>> on behalf of Robert Kraft <[log in to unmask]<mailto:[log in to unmask]>>
Reply-To: FSL - FMRIB's Software Library <[log in to unmask]<mailto:[log in to unmask]>>
Date: Wednesday, 27 April 2016 15:58
To: "[log in to unmask]<mailto:[log in to unmask]>" <[log in to unmask]<mailto:[log in to unmask]>>
Subject: [FSL] epireg
I am using epireg called through the FEAT gui to perform motion correct, distortion correction and boundary based registration for preprocessing resting state fMRI data. Everything seems fine but I have noticed that in about 10% of my data there appears to be approximately a 1% change in the global signal intensity around the reference volume used for motion correction. The global signal intensity change is not present in the original data. The change is positive at it approaches the reference volume and then switches signs after the reference volume. The signal change then returns back to the normal mean for volumes further away from the reference.
When I run fsl_motion_outliers on this data with the -nomoco option it identifies these central volumes as outliers. If I run the fsl_motion_outliers on the original data without the -nomoco flag it identifies only a few outliers but they are not clustered around the reference volume. I am hoping that someone could explain this behavior.
I have also run the data using the first volume as a reference. This resulted in a different set of outliers being identified. The data sets that I am working with have very little motion (less than 0.5mm). I am also using a non-FSL tool (ART https://www.nitrc.org/projects/artifact_detect/). This tool is also identifying outliers but only based upon the change in global signal intensity around the reference volume.
It seems that these small global signal intensities changes is causing the outlier detection tools to identify a large portion of outliers (20-42) volumes out of 190. I am still trying understand and isolate the problem. Any suggestion on why this is occurring would be greatly appreciated.
Has anyone else encountered this issue? What is the appropriate way to identify outliers? Should I just do it on the raw data and not worry about the changes in global signal intensity. I suspect that these changes won't affect the analysis because they will be regressing them out with CompCorr.
Thanks for your help and advice.
Bob
Original data with motion correction
➜ fsl_motion_outliers -i epi.nii.gz -o fslmo.txt -p dvars.png -s dvars.txt
➜ cat -n fslmo.txt | grep " 1 "
96 0 1 0 0 0 0
97 0 0 1 0 0 0
117 0 0 0 1 0 0
126 0 0 0 0 1 0
138 0 0 0 0 0 1
Original data without motion correction
➜ fsl_motion_outliers -i epi.nii.gz -o fslmo.txt -p dvars.png -s dvars.txt --nomoco
➜ cat -n fslmo.txt | grep " 1 "
96 0 1 0 0 0 0
97 0 0 1 0 0 0
126 0 0 0 1 0 0
138 0 0 0 0 1 0
143 0 0 0 0 0 1
The outliers identified are the same with and without the motion correction flag. After I perform EPIREG and BBR the situation is very different.
Output of bold.nii after epireg. Reference is center volume
➜ fsl_motion_outliers -i filtered_func_data.nii.gz -o fslmo.txt -p dvars.png -s dvars.txt --nomoco
➜ cat -n fslmo.txt | grep " 1 "
83 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
84 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
85 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0
91 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0
92 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0
93 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0
94 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0
95 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0
96 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0
97 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0
98 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0
99 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0
100 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0
101 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0
102 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0
103 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0
173 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1
|