Hi,
I must admit that I am very surprised by this, as increasing the
paddingsize
sufficiently should always work. It cannot be about the signal
magnitude,
as that doesn't enter into this calculation, unless there is an issue
with
it being forced into an integer type. Try with "-datatype float" and
see
if that makes a difference. Also, what values of paddingsize are you
trying?
I assume that the registrations look reasonable and it is not because
one
is a long way off.
I think it is definitely better to try and stick with standard flirt
and no
interpolated motion correction if possible. Hopefully we can sort out
what is causing this very strange behaviour.
All the best,
Mark
On 31 Mar 2009, at 12:17, 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 (not the end slices in general)
> -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
>
|