[Mrtrix-discussion] Motion correction best practise

Mon Dec 2 02:20:15 PST 2013

Hi Ivan,

Just to add since you specifically asked. I have recently tried eddy_correct and eddy on a b=1500 data set. eddy_correct gave poor results and as Donald suggested introduced artefacts where the images were stretched along the AP direction to a far greater extent than the raw data. My data had motion artefact during the acquisition so I tried eddy and this worked really well - it corrected the motion without introducing the stretching. It takes significantly longer though than eddy_correct.

I hope that's useful

Jonathan

MRI Physicist
Kings College Hospital
Ruskin Wing
Denmark Hill
London SE5 9RS
Ph (KCH): 020 3299 9000 (x4898)
Ph (CNS): 020 3228 3081
fax (CNS): 020 3228 2116

________________________________
From: mrtrix-discussion-bounces at www.nitrc.org <mrtrix-discussion-bounces at www.nitrc.org> on behalf of Ivan Alvarez <ivan.alvarez.11 at ucl.ac.uk>
Sent: 19 November 2013 13:26
To: mrtrix-discussion at www.nitrc.org
Subject: Re: [Mrtrix-discussion] Motion correction best practise

Hi Romain,

This is straying into a FSL-specific question, but I'll ask anyway since we're on the topic - Am I correct in understanding that Eddy does a) motion correction and b) eddy current correction in its base form, with the optional bonus step of c) EPI distortion under Topup?

I ask because in the manual it states Topup requires your DWI data and also a b0 volume with the opposite phase-encoded direction.

Kind regards,
Ivan Alvarez

PhD Candidate
Imaging and Biophysics Unit
UCL Institute of Child Health
30 Guilford Street, London, WC1N 1EH

On 19/11/13 09:20, romain valabregue wrote:
Hello,

the artefact added with eddy_correct is more pronounce for high bvalue (3000) with 1000 or 1500 it should go better
For the bvec correction it is a tiny effect so it does not matter that much, (that's why it is not in there priority list), if you run eddy_correct you can use the extra script fdt_rotate_bvecs

The eddy procedure is much better : this is mainly because in addition to motion it also correct the distorsion due to eddy current. (and also EPI distorsion with topup). The main limitation is that it require a specific acquisition (either the direction have to be over the all sphere or you need each direction with direct and oposite phase direction), but It worth to change your dwi acquisition.

I hope it helps

Romain

Le 18/11/2013 23:39, Jeurissen Ben a écrit :
Hi all,

FSL's "eddy_correct" doesn't do b-matrix rotation. They do offer a separate script to reorient the bvecs file after running eddy_correct, though.

FSL5's "eddy" doesn't do b-matrix rotation either and there is no script available to reorient the bvecs file. On their mailinglist the developers stated developing such a tool is currently not high on their priority list.

Hope this clarifies the state of b-matrix rotation in FSL.

Cheers,
Ben

-
Ben Jeurissen, Ph.D.
Post-doctoral researcher
Vision Lab, Dept. of Physics
University of Antwerp
Universiteitsplein 1, N.1.18
B-2610 Wilrijk, Belgium
Phone: +32 3 265 24 77
Email: ben.jeurissen at ua.ac.be<mailto:ben.jeurissen at ua.ac.be>
Url: http://visielab.ua.ac.be/people/ben-jeurissen
________________________________
From: mrtrix-discussion-bounces at public.nitrc.org<mailto:mrtrix-discussion-bounces at public.nitrc.org> [mrtrix-discussion-bounces at public.nitrc.org<mailto:mrtrix-discussion-bounces at public.nitrc.org>] on behalf of Ivan Alvarez [ivan.alvarez.11 at ucl.ac.uk<mailto:ivan.alvarez.11 at ucl.ac.uk>]
Sent: 18 November 2013 13:31
To: Donald Tournier
Cc: mrtrix mailinglist
Subject: Re: [Mrtrix-discussion] Motion correction best practise

Hi Donald,

Thank you for all your comments.

I was not aware FSL did b-matrix update, will definitely look into this.

It's interesting that you mention we may be loosing more than we are gaining with motion correction, particularly with the introduction of artefacts and poor registration at high b-values. Is there a rule of thumb for when are such procedures useful/detrimental? For example, in fMRI movement >5mm within a single run (i.e. 5-10 minutes continuous scanning) is considered worrisome but salvageable and >10mm is often too much to be rescued by registration. Is there something like that for dMRI?

PS The Gaussian process code is now in FSL under the name EDDY ( http://fsl.fmrib.ox.ac.uk/fsl/fslwiki/EDDY). I haven't personally tried it, but would love to hear from other users!

Kind regards,
Ivan Alvarez

PhD Candidate
Imaging and Biophysics Unit
UCL Institute of Child Health
30 Guilford Street, London, WC1N 1EH

On 18/11/13 12:15, Donald Tournier wrote:
Hi Ivan,

I'm probably not the best person to ask about this... There's a few other people on this list whose opinion on the matter is much better informed than mine, I cordially invite them all to chip in. ;)

I've no experience with ExploreDTI, but you can ask Alex Leemans directly through the ExploreDTI mailing list. That said, I'm fairly confident it does the b-matrix update...

As to FSL, as far as I know it also does volume-wise affine registration, and it is possible to do the b-matrix update, although I'm not familiar with the procedure needed to do this.

I'm not familiar with any package that does slice-by-slice registration, but my gut feeling on the matter is that there's probably not a great deal of point to doing this as slice-wise mis-registration is generally accompanied by through-plane motion, which will cause signal corruption due to spin history effects. For this reason, I'd consider the entire volume affected to be corrupt in this case: even if there is no obvious signal drop, the chances are there will be some corruption. That said, it might be worth doing if your downstream processing pipeline has a way of handling outliers, etc.

I'd also like to highlight that these approaches are still far from perfect. I've already raised the issue on this list, but based on my limited exposure to FSL's eddy_correct (which seems to be what most people use), I think it often creates more problems than it solves. I hasten to add that this problem may also apply to other approaches, but so far I've only been exposed to data processed using eddy_correct. I've come across many cases where the coregistration introduces artefacts, even when the original data wasn't particularly affected in the first place. These artefacts typically consist of the DW images being stretched along one or more axes, probably because the algorithm tries to match the parenchyma bit of the DW volumes to the parenchyma+CSF parts of b=0 volume. This is particularly pronounced with high b-value data, but I've also seen it happen in run-of-the-mill b=1000 data too (as recently as a couple of weeks ago, in fact). All this to say, if you use these tools, please don't treat them as a black box, do check that they're working as expected.

On the upside, Jesper Anderson recently proposed a new approach based on Gaussian processes, which I think has now made it into FSL5. If any other users have tried using it, feel free to comment on this...

Cheers,
Donald.

On 18 November 2013 03:06, Ivan Alvarez <ivan.alvarez.11 at ucl.ac.uk<mailto:ivan.alvarez.11 at ucl.ac.uk>> wrote:
Hi Donald,

I wanted to bring up motion correction again, particularly what is recommended for and against in MRtrix. I am aware the issue has been raised in the mailing list before, but it might be useful to have an idea of what is generally a good or bad idea.

So far, I have seen people doing motion/eddy-current correction in either ExploreDTI or FSL. The documentation for both is these is somewhat scant and I am trying to piece together what do they exactly do. This is my naive reading so far, please feel free to correct me:

ExploreDTI
* Affine registration
* Whole volume at a time
* Updates B-matrix

FSL
* Affine registration
* Slice-by-slice
* Does not update B-matrix

>From what I understand in the discussion, the slice-by-slice registration is preferable to avoid smearing artefacts across the whole volume while updating the B-matrix can generally improve results (http://www.ncbi.nlm.nih.gov/pubmed/19319973). Is this roughly correct? If so, are there any other considerations specific to MRtrix?

--
Kind regards,
Ivan Alvarez

PhD Candidate
Imaging and Biophysics Unit
UCL Institute of Child Health
30 Guilford Street, London, WC1N 1EH

_______________________________________________
Mrtrix-discussion mailing list
Mrtrix-discussion at www.nitrc.org<mailto:Mrtrix-discussion at www.nitrc.org>
http://www.nitrc.org/mailman/listinfo/mrtrix-discussion

--
Dr J-Donald Tournier (PhD)

Senior Lecturer, Biomedical Engineering
Division of Imaging Sciences & Biomedical Engineering
King's College London

A: Department of Perinatal Imaging & Health, 1st Floor South Wing, St Thomas' Hospital, London. SE1 7EH
T: +44 (0)20 7188 7118 ext 53613
W: http://www.kcl.ac.uk/medicine/research/divisions/imaging/departments/biomedengineering

_______________________________________________
Mrtrix-discussion mailing list
Mrtrix-discussion at www.nitrc.org<mailto:Mrtrix-discussion at www.nitrc.org>
http://www.nitrc.org/mailman/listinfo/mrtrix-discussion

_______________________________________________
Mrtrix-discussion mailing list
Mrtrix-discussion at www.nitrc.org<mailto:Mrtrix-discussion at www.nitrc.org>
http://www.nitrc.org/mailman/listinfo/mrtrix-discussion

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.nitrc.org/pipermail/mrtrix-discussion/attachments/20131202/400c84f1/attachment-0001.html>