Hi Jesper,
But in terms of the “RMS” values, the centre of the rotation should be irrelevant, right?

This speaks to an issue that I haven’t had a chance to look into yet.  Namely, are the values returned in the new .eddy_restricted_movement_rms file much more similar in magnitude to those that are returned by MCFLIRT?

thanks,
-MH

-- 
Michael Harms, Ph.D.
-----------------------------------------------------------
Conte Center for the Neuroscience of Mental Disorders
Washington University School of Medicine
Department of Psychiatry, Box 8134
660 South Euclid Ave. Tel: 314-747-6173
St. Louis, MO  63110 Email: [log in to unmask]

From: FSL - FMRIB's Software Library <[log in to unmask]> on behalf of Jesper Andersson <[log in to unmask]>
Reply-To: FSL - FMRIB's Software Library <[log in to unmask]>
Date: Thursday, September 8, 2016 at 11:40 AM
To: FSL - FMRIB's Software Library <[log in to unmask]>
Subject: Re: [FSL] Problems with eddy tool

Dear Mahmoud,

you cannot directly compare the movement parameters between mcflirt and eddy since they don’t use the same convention for parameter->transformation_matrix. In particular mcflirt uses the centre of voxel 0,0,0 as centre of rotation whereas eddy uses the centre of the FOV.

Hence I would expect the rotations to be “similarish”, but the translations to be (possibly very) different.

Jesper

 
On 8 Sep 2016, at 17:25, Mahmoud <[log in to unmask]> wrote:

Dear Jesper,

Thank you for your advice.
I have another question for you:

I've already used the mcflirt output to extract the translation and rotation parameters with respect to the first (b0) volume.
I repeated the parameters extraction using the *.eddy_parameters outputted by the new eddy.

Comparing the parameters from those two methods (i.e. mcflirt and new eddy) reveals a big difference between them. You've already mentioned that new eddy's outputs are more accurate but I'm not sure how I can justify this big difference. Please kindly advise.

Thank you!
Mahmoud

On Thu, Sep 8, 2016 at 9:55 AM, Jesper Andersson <[log in to unmask]> wrote:
Hi Mahmoud,


Could you please let me know whether or not the following is correct:

How much subject moved ~  (*.eddy_movement_rms) - (*.eddy_restricted_movement_rms)

no, those are two alternative “views” on how much the subject moved. 

A problem with assessing how much a subject actually moved from registering diffusion data is that there is an almost total co-linearity between an non-zero mean of an EC induced gradient and an actual subject movement in the PE direction (typically y). From a perspective of correcting the data it doesn’t matter if we assign it to EC or movement, the end result corrected images are identical. 

But from the perspective of telling “how much” a subject moved (presumably for QC reasons) it can make a difference. That means that if we include translations in the PE direction in the estimate (as in .eddy_movement_rms) we likely overestimate movement. If instead we exclude translations in the PE direction (as in .eddy_restricted_movement_rms) we likely underestimate it. But there is really no way we can know the full “truth”.

My recommendation is to use .eddy_restricted_movement_rms and accept that it is likely to be a slight underestimation, but one that will still give you the info you need in terms of relative amount of movement across subjects.

Jesper


Thank you!
Mahmoud

On Mon, Aug 29, 2016 at 9:44 AM, Jesper Andersson <[log in to unmask]uk> wrote:
Dear Mahmoud,

Regarding the eddy_openmp:

1- I am assuming that the translation and rotation values in *.eddy_parameters are in mm and radian, right?

yes.


2- Are the above motion parameters from the alignment of each volume to the first b0 volume? if not, how can we specify that?

They are relative the first volume of the 4D file you specified for your --imain.


3- Should we expect any difference between the motion parameters driven from mcflirt and eddy_openmp outputs? if yes, which one is more accurate/preferable?

The eddy output should be considerably more accurate. But typically you would never need to actually use the motion parameters for anything.

Jesper



Thank you!
Mahmoud

On Wed, Aug 17, 2016 at 11:29 AM, Jesper Andersson <[log in to unmask]k> wrote:
Hi again,

that is right.

Jesper


On 17 Aug 2016, at 16:27, Mahmoud <[log in to unmask]> wrote:

Dear Jesper,

If the MB factor is 2 and number of slices is even it means that no slice was removed from top or bottom, and I shouldn't use the --mb_offs, right?

Thank you,
Mahmoud

On Wed, Aug 17, 2016 at 10:58 AM, Jesper Andersson <[log in to unmask]k> wrote:
Dear Mahmoud,

the help pages are at


I am literally now writing the help text. I am struggling quite badly with the moinwiki (just don’t get me started!), so it is taking a little longer than I had hoped for. But the --mb and the reason for why you might want to use it should already be there.

Jesper


On 17 Aug 2016, at 15:49, Mahmoud <[log in to unmask]> wrote:

Hello Jesper,

Is there a manual for eddy_openmp that describes the optional arguments in more details?
For example, how helpful would be to use the --mb switch? My data is acquired with MB=2 and GRAPPA=2 . Do I have to add --mb 2 to eddy_openmp command line?

Thank you,
Mahmoud

On Wed, Aug 17, 2016 at 6:09 AM, Jesper Andersson <[log in to unmask]k> wrote:
Dear Michele,

this is a known problem for some acquisition schemes. The patch that was released yesterday will address this issue through the --data_is_shelled flag.

Jesper

On 27 Jul 2016, at 16:46, Michele Guerreri <[log in to unmask]> wrote:

> Hi,
>
> I'm trying to use eddy tool to correct my DW data. When I run the tool i receive these message:
>
> I'm thrown
> terminate called after throwing an instance of 'EDDY::KMatrixException'
>   what():  KMatrixException: msg=MultiShellKMatrix::SetDiffusionPar: Data not shelled
> Aborted
>
> In my experiment I'm using one b_0 and 11 b-values from 200 to 5000 s/mm^2. For each b-value I have 15 directions.
> I have already used eddy on the same data but dividing the 166 4D-volume in three separate 4D-volumes and it worked.
>
> Thank you in advance.
>
> Michele.










 


The materials in this message are private and may contain Protected Healthcare Information or other information of a sensitive nature. If you are not the intended recipient, be advised that any unauthorized use, disclosure, copying or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this email in error, please immediately notify the sender via telephone or return mail.