# Dwipreproc and inter-protocol motion
**URL:** https://community.mrtrix.org/t/dwipreproc-and-inter-protocol-motion/1046
**Category:** Blog
**Tags:** preprocessing
**Created:** [July 21, 2017, 4:36am UTC](https://community.mrtrix.org/t/dwipreproc-and-inter-protocol-motion/1046 "2017-07-21T04:36:57Z")
**Posts on this page:** 4
**Page:** 1
### Author:  [@rsmith](https://community.mrtrix.org/u/rsmith)
#### Post date: [July 21, 2017, 4:36am UTC](https://community.mrtrix.org/t/dwipreproc-and-inter-protocol-motion/1046/1 "2017-07-21T04:36:58Z")
Hi all,
There is an ongoing issue / discussion around the `dwipreproc` script, particularly with regards to a common use case: combination of the `-rpe_pair` and `-se_epi` options to provide reversed phase-encode spin-echo images with which to estimate the inhomogeneity field, which are then used to geometrically correct a set of DWIs that were all acquired with a fixed phase encoding (issue originally raised [here](https://community.mrtrix.org/t/dwipreproc-register-fieldmap-to-dwi-other-questions/621)). The issue is that the `dwipreproc` script fails to take into account the possibility of subject motion between acquisition of those volumes used to estimate the field, and acquisition of the DWIs to which the geometric correction is to be applied.
Although I made an attempt to provide an integrated solution to this issue within `dwipreproc` as part of the impending `3.0_RC2` tag update, that solution had to be discarded, as it did not generalise to all use cases and may therefore have led to erroneous pre-processing of some user data, without warning. So unfortunately I’m issuing a warning instead of a solution…
I’ve tried to provide a more user-friendly interface to `topup` and `eddy` to satisfy user requirements and simplify data pre-processing, but the `dwipreproc` script is still _not_ a one-button “magic bullet” that will apply the appropriate pre-processing for all plausible acquisitions. There is therefore a certain degree of diligence required from users to ensure that the image processing algorithms they use are indeed applicable to their particular data, and are applied correctly. I cannot emphasise enough the importance of manual data checking.
With regards specifically to the issue of inter-protocol motion, there is a technique that users can employ manually in order to overcome the issue (this was additionally described somewhere on the FSL mailing list; unfortunately I can’t seem to find it, if someone has the link feel free to post it here). If the first volume in the `topup` input image is the _same volume_ as the first volume in the `eddy` input, then the estimated inhomogeneity field will be intrinsically aligned with the frame of reference used in `eddy` when applying that field. This can be achieved by:
- Extracting the first volume from the DWIs: `mrconvert dwi.mif first_bzero.mif -coord 3 0`
- Concatenating this volume with the reversed phase-encode images to be provided via `dwipreproc`'s `-se_epi` option, ensuring that this volume is the _first_ volume in the output image: `mrcat first_bzero.mif se_epi.mif se_epi_with_bzero.mif -axis 3`.
- Running `dwipreproc` as normal, providing the `se_epi_with_bzero.mif` image using the `-se_epi` option.
**However** , there are certain assumptions within this correction that may not hold for all use cases. If _any_ of these conditions do not hold, then the technique outlined above is not applicable to your data:
- Your SE-EPI images and DWIs have a different TE.
- Your SE-EPI images and DWIs have a different TR (for instance, if your DWIs are acquired using a multi-band sequence, but the reversed phase-encode images were acquired using single-band).
- Your SE-EPI images and DWIs have different effective bandwidths (for instance, if one uses GRAPPA but the other does not).
- Your SE-EPI images and DWIs do not have the same dimensions and voxel sizes in the three spatial axes.
- The first DWI volume is not a _b_=0 volume (though this can be mitigated with a bit of `mrconvert` trickery).
If this correction cannot be applied to your data, unfortunately I do not have a copy-and-paste solution for you. I would most definitely recommend checking for motion between the first SE-EPI volume and the first DWI volume of each subject to see the extent to which inter-protocol motion may be a problem for you. I do plan to try an alternative technique for automatically correcting for such inter-protocol motion within `dwipreproc`, but this will take some time to develop and validate.
Regards
Rob
---
### Author:  [@Hamed](https://community.mrtrix.org/u/Hamed)
#### Post date: [April 24, 2018, 9:50am UTC](https://community.mrtrix.org/t/dwipreproc-and-inter-protocol-motion/1046/2 "2018-04-24T09:50:13Z")
Hi Rob
> [@rsmith](#):
>
> (this was additionally described somewhere on the FSL mailing list; unfortunately I can’t seem to find it, if someone has the link feel free to post it here).
I guess this is the link. 🙂
[https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind1703&L=fsl&D=0&1=fsl&9=A&J=on&d=No+Match%3BMatch%3BMatches&z=4&P=305058](https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind1703&L=fsl&D=0&1=fsl&9=A&J=on&d=No+Match%3BMatch%3BMatches&z=4&P=305058)
Cheers,
Hamed
---
### Author:  [@rsmith](https://community.mrtrix.org/u/rsmith)
#### Post date: [May 11, 2018, 2:13pm UTC](https://community.mrtrix.org/t/dwipreproc-and-inter-protocol-motion/1046/3 "2018-05-11T14:13:49Z")
For those interested in this topic:
With the [release](https://community.mrtrix.org/t/mrtrix-3-0-release-candidate-3/1624) of _MRtrix3_ version `3.0_RC3`, script `dwipreproc` now has an additional command-line option `-align_seepi`. The functionality enabled by this option is comparable to the details described above: It inserts the first _b_=0 volume from the DWI series to the start of the image series provided to `topup`, in order to achieve “alignment” between estimation of the inhomogeneity field from the spin-echo EPIs provided to `topup` and the correction of inhomogeneity field distortions within `eddy`. The fundamental requirement that must be satisfied for this approach to work is that the _contrast_ within the DWI _b_=0 image must match that of the SE-EPI series; this includes TE, TR and flip angle.
I’ve tried to make the script reasonably clever at figuring out when it can v.s. cannot perform such a correction, and to do so in the appropriate manner for all possible use cases of the script; but please do be critical of its operation rather than trusting it blindly, especially with such new features. I do however hope that this provides a convenient mechanism for ensuring that inter-protocol subject motion does not lead to gross errors in DWI distortion correction.
Cheers
Rob
---
### Author:  [@rsmith](https://community.mrtrix.org/u/rsmith)
#### Post date: [July 27, 2020, 6:25am UTC](https://community.mrtrix.org/t/dwipreproc-and-inter-protocol-motion/1046/4 "2020-07-27T06:25:20Z")
A post was split to a new topic: [Dwifslpreproc and motion correction](https://community.mrtrix.org/t/dwifslpreproc-and-motion-correction/3953)