On Fri, Aug 3, 2012 at 11:23 AM, Christopher Bell
<[log in to unmask]> wrote:
> All,
>
> This was a very interesting discussion. I was wondering if people commonly
> do motion regression
> in the context of GLM and if not, why is it avoided?

Please read the following papers:
Motion correction and the use of motion covariates in multiple-subject
fMRI analysis.
Johnstone T, Ores Walsh KS, Greischar LL, Alexander AL, Fox AS,
Davidson RJ, Oakes TR.
Hum Brain Mapp. 2006 Oct;27(10):779-88.

Comparison of fMRI motion correction software tools.
Oakes TR, Johnstone T, Ores Walsh KS, Greischar LL, Alexander AL, Fox
AS, Davidson RJ.
Neuroimage. 2005 Nov 15;28(3):529-43. Epub 2005 Aug 15.

Evaluation and optimization of fMRI single-subject processing
pipelines with NPAIRS and second-level CVA.
Zhang J, Anderson JR, Liang L, Pulapura SK, Gatewood L, Rottenberg DA,
Strother SC.
Magn Reson Imaging. 2009 Feb;27(2):264-78. Epub 2008 Oct 11.

I guess I could ask the
> same question of WM, WB and CSF regression. It seems the analysis method
> very much drives the pre-processing methods. Is the worry simply killing
> task-related signal that is also correlated with motion? It seems this is
> the non-conservative approach. Sorry to
> switch the discussion slightly.

Removing the global brain signal will increase the activations and
deactivations since it pushes the two signals apart. By pushing them
apart, the signal is altered and you could have two activations that
then become an activation and deactivation if you have enough
activation in the brain. Since you now have deactivations that did not
exist before, they are hard to interpret.This is why people don't do
it.


>
> Chris
>
>
> On Thu, Aug 2, 2012 at 4:16 PM, Mark Jenkinson <[log in to unmask]> wrote:
>>
>> Hi Satra,
>>
>> The numbers that Jesper and I are coming up with are based on the fairly
>> simple calculation of partial volume.
>> If the intensity difference at the ventricular CSF boundary (or any edge)
>> is about 50% of the mean intensity, and the movement is about 0.1 of a voxel
>> (i.e. 10% of a voxel size or only 0.3mm for a 3mm voxel) then the expected
>> intensity change at that edge voxel is 50 * 0.1 = 5% of the mean intensity.
>> This would occur in the original image due to motion and is the sort of
>> signal change that could then get "locked in" by slice-timing-correction if
>> it were applied before motion correction.
>>
>> If prospective motion correction is reducing motion to less than 0.02 of a
>> voxel (which is equivalent to a change of 1% signal from the above
>> reasoning) then it would get into the regime where temporal signal changes
>> might be bigger than spatial ones.  However, 0.02 * 3 is only 0.06mm and I
>> do not think that these methods are that accurate yet.  So in that case it
>> would not change the fact that the motion-induced error remains larger, and
>> hence our recommendation would remain the same.
>>
>> All the best,
>> Mark
>>
>>
>>
>> On 2 Aug 2012, at 13:35, Satrajit Ghosh wrote:
>>
>> hi all,
>>
>> thanks for the discussion on this issue.
>>
>> in the context of siemens scanners, prospective motion correction is often
>> built into the BOLD sequences these days. would this discussion be
>> applicable in this context as well?  i.e. given the automatic slice
>> reconfiguration, would the ratio of motion to slice timing related error be
>> much closer?
>>
>> also, jesper and mark, where are you getting the numbers from relating
>> voxel displacement to signal change?
>>
>>> In summary, it is a messy, complicated issue and the existing methods are
>>> not perfect (a 4D interpolation would be better).
>>
>>
>> a 4d registration algorithm actually exists that can handle slice timing +
>> motion correction in one step.
>>
>> Roche A. A four-dimensional registration algorithm with application to
>> joint correction of motion and slice timing in fMRI. IEEE Trans Med Imaging.
>> 2011 Aug;30(8):1546-54.
>>
>> http://dx.doi.org/10.1109/TMI.2011.2131152
>>
>> and is available in the NiPy package:
>>
>> nipy.org/nipy/stable/api/generated/nipy.algorithms.registration.groupwise_registration.html#fmrirealign4d
>>
>> and wrapped for NiPype:
>>
>> nipy.org/nipype/interfaces/generated/nipype.interfaces.nipy.preprocess.html#fmrirealign4d
>>
>> cheers,
>>
>> satra
>>
>>
>