Hi Erin,
I find this really puzzling.
Would you be able to send us your data?
This, and the *exact* commands you've been running,
will hopefully help us find the problem and sort it out.
You can upload the data at the website:
http://www.fmrib.ox.ac.uk/cgi-bin/upload.cgi
Once you've done that, send us the reference number
and the commands you've been running.
All the best,
Mark
Mazerolle, Erin wrote:
> 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?
>
> Thanks again!
>
> Erin
>
>
> ================================================================================================
>
>
> 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.
>
> Cheers.
>
>
> 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
>> thickness
>> (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
>> intensity
>> differences either.
>>
>> I should also note that when I use 12 DOF (i.e., eddy_correct 's
>> default
>> 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
>> acquisitions).
>>
>> Thanks for any ideas!
>>
>> Erin
>>
>>
>>
>>
>>> 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
>>>
>>> Cheers.
>>>
>>
>> On 16 Feb 2009, at 18:37, Mazerolle, Erin wrote:
>>
>>
>>> Hello,
>>> 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?
>>> Thanks!
>>> Erin
>>>
>
>
