Hi again Steve et al
I have a little bit more evidence related to the problem that I thought I would share, given that you mentioned you are surprised that the dofs are changing the end-slice behaviour.
-sometimes increasing the paddingsize helps, but sometimes it doesn't
-even when I use dof = 7, the end slices look fine (the problem only occurs for dof = 6)
-it is always the most inferior slice
-the problem is worsened at higher b-values (larger parts of the most inferior slice are cut off, again only with dof = 6)
Given the last point, I am wondering if this is more of a problem with using flirt on volumes with very low signal, rather than a problem with movement in my data? I'm very interested to hear any thoughts people might have. Would it be better to just run flirt on my b = 0 images, and interpolate the motion corrections on the intervening diffusion weighted images?
Hi - I'm a little surprised that you would get different end-slice
behaviour in the dof=6 and 12 cases, but if this is just due to very
slight rotations out of volume then you can reduce that with the -
paddingsize option. I would not use mcflirt as it is not at all
optimised for this scenario.
On 9 Mar 2009, at 20:53, Mazerolle, Erin wrote:
> Hi Steve et al
> Thanks very much. I tried this but I find that it results in parts
> of my
> most inferior slices being cut off. I checked using mcflirt and it
> doesn't appear that I have motion that is larger than my slice
> (3mm slices versus 0.002 radians & 0.6mm motion params). Do you
> think it
> would be reasonable to use mcflirt instead of the flirt call in
> eddy_correct? I am worried that mcflirt might get confused by the
> differences in intensity between diffusion weighted versus b=0, but I
> don't understand how eddy_correct 's flirt call handles these
> differences either.
> I should also note that when I use 12 DOF (i.e., eddy_correct 's
> flirt call), my inferior slices are not cut off. Basically the only
> problem with using the 12 DOF is conceptual - there shouldn't be any
> shearing & stretching caused by eddy currents in my spiral data (I
> believe eddy currents are more likely to appear as blurring in spiral
> Thanks for any ideas!
>> Hi - you're mostly right, you won't get eddy correction in this case
>> but you can still correct for head motion. However, you may as well
>> constrain the degrees-of-freedom to be rigid body in this case, so
>> take a local copy of eddy_correct and add the following flag to the
>> flirt call (just before the ">>"):
>> -dof 6
> On 16 Feb 2009, at 18:37, Mazerolle, Erin wrote:
>> I was hoping someone could tell me if it is valid to run FSL's eddy
>> current correction with diffusion data collected using a spiral
>> trajectory. I don't imagine it would be able to correct for eddy
>> currents due to the difference in trajectory, but can it still do
>> the motion correction across images with different bvalues?