Hi Pete.
One thing to keep in mind is that if your experiment is related to
the resting-state of motor-related areas, then the correction of a
significant head motion in this way may not solve all of your problems.
A head motion like that will significantly modulate the hemodynamic
response in motor areas that will extend in time beyond the time of
motion, and may be evident in the time course.
Hence, you may not have a true resting state anymore. At least this
has been our experience. We have tried to use an additional regressor
to model the hemodynamic response to the head motion, but have had
little success. We found that it's best to collect several runs and
discard any with motion artifacts.
-Brad
On Jul 5, 2007, at 10:14 AM, Doug Greve wrote:
> Pete,
>
> The right way to remove a time point is to add a regressor (custom
> 1-column) with 1 at that time point and 0 everywhere else. Do NOT
> convolve with a shape or add a deriviative. DO apply temporal
> filtering
> if you are using it on your data. If you have a 2nd time point to
> remove, then add another regressor (don't put a 2nd 1 in your 1st
> regregressor).
>
> doug
>
>
>
>
> On Thu, 5 Jul 2007, Peter Fried wrote:
>
>> Hi,
>>
>> I have a question about correcting for motion in resting-state
>> fmri data.
>>
>> We collect 180 volumes (TR=2s) of fmri data during a resting-
>> state. The
>> data is first processed using the pre-stats tab under FEAT. The
>> parameters
>> we use are:
>>
>> Motion Correction (mcflirt)
>> B0 unwarping
>> Slice-timing correction
>> Bet brain extraction
>> Spatial smoothing FWHM = 6 mm
>> Intensity Normalisation
>> Highpass temporal filtering
>>
>> plus, Melodic
>>
>> Here's the problem: MCFLIRT seems to do a good job when there is
>> gradual
>> movement over the course of the scan. However, if there is a sudden
>> movement (say, the subject coughed or jerked their arm), MCLFIRT
>> does not
>> seem to be able to correct it. To make matters worse, there are often
>> motion spikes that show up in the timecourse of non-motion
>> components.
>>
>> We've tried filtering out some of the worst melodic components,
>> but that
>> doesn't seem to effect components that have been (for lack of a
>> better
>> term) corrupted by motion. The best results we've had have been from
>> splitting the 4D volume, removing the volumes with the most motion
>> and
>> merging the remaining volumes back together. Even though we don't
>> have a
>> block design, I'm still wary of doing this, especially if there is a
>> better way.
>>
>> Here's my question: Is there any way to do a more robust
>> elimination of
>> motion, other than the parameters I've mentioned above? Also, should
>> deleting volumes be avoided at all costs or is it okay to remove a
>> few
>> with bad motion?
>>
>> Thanks.
>> -Pete
>>
>>
>>
>
> --
> Douglas N. Greve, Ph.D.
> MGH-NMR Center
> [log in to unmask]
> Phone Number: 617-724-2358 Fax: 617-726-7422
>
> In order to help us help you, please follow the steps in:
> surfer.nmr.mgh.harvard.edu/fswiki/BugReporting
>
>
|