# Dwifslpreproc and motion correction **URL:** https://community.mrtrix.org/t/dwifslpreproc-and-motion-correction/3953 **Category:** Uncategorized **Tags:** preprocessing **Created:** [July 24, 2020, 2:07am UTC](https://community.mrtrix.org/t/dwifslpreproc-and-motion-correction/3953 "2020-07-24T02:07:29Z") **Posts on this page:** 1 **Showing post:** 2
### Author: ![rsmith](https://community.mrtrix.org/user_avatar/community.mrtrix.org/rsmith/32/2672_2.png) [@rsmith](https://community.mrtrix.org/u/rsmith) #### Post date: [July 27, 2020, 7:39am UTC](https://community.mrtrix.org/t/dwifslpreproc-and-motion-correction/3953/2 "2020-07-27T07:39:07Z")
Hi Peter, I’ve moved your questions from their original location to a new thread, as there’a bit to disentangle here that is quite distinct to the original purpose of the [blog post](https://community.mrtrix.org/t/dwipreproc-and-inter-protocol-motion/1046) on DWI inter-protocol motion. * * * P.S. If _anyone_ is ever unsure as to whether to make a response to an existing thread or write a new thread, personally I’d suggest erring towards the latter, including a link to the existing thread(s) using the syntax shown [here](https://community.mrtrix.org/t/formatting-tricks-for-increased-readability/34). It’s much easier to understand a dedicated thread that has relationships to other linked threads, than having multiple trains of thought going on within a single thread that end up diverging from the original thread title / purpose. The web hosting costs don’t scale as a function of the number of topics! 😛 Not at all picking on you @KangMSPeter, just a general suggestion for all. * * * Okay, let’s see how we go teasing this all apart. > … regarding the motion correction within `dwifslpreproc` based on the `-align_seepi`. The main problem is initially flagged here, and I think it’s better to identify it up front before getting into the weeds. `dwifslpreproc` will _always_ perform motion correction, _regardless_ of how you use it or what data it is provided with. This, along with eddy current correction, is at the core of the FSL `eddy` command that `dwifslpreproc` provides an interface to. The specific issue that is described in the [blog post](https://community.mrtrix.org/t/dwipreproc-and-inter-protocol-motion/1046) is that of _inter-protocol_ motion; that is, when you run one sequence on the scanner, the subject fidgets around a little bit because the scanner stopped making noises, and you then run another sequence. But motion in between DWI volumes will always be corrected. It’s also worth being explicit about the fact that use of the `-align_seepi` doesn’t actually invoke any explicit alignment step of any kind. It’s more like “precluding misalignment” that may arise due to the assumptions made in the nature of the data provided to FSL’s `topup` and `eddy` commands. > To me, it seems as though the motion correction is being taken care of by including the `-se_epi` & `-align_seepi` options. The `-se_epi` option is independent of motion correction; it is used when EPI distortion correction is to be performed, but the requisite data for estimating the inhomogeneity field for performing said correction aren’t present in the input DWI data, and therefore these data need to be provided explicitly. In the absence of this option, motion correction will still be performed. The `-align_seepi` option _only_ applies in the specific instance where there is the possibility of there having been motion _in between_ acquisition of the DWIs and acquisition of the data being provided via the `-se_epi` option, _and_ the steps described in the [blog post](https://community.mrtrix.org/t/dwipreproc-and-inter-protocol-motion/1046) are valid. > … to verify further on `-rpe_all`, MRtrix doc recommends to concatenate the primary and reverse phase DWI data together and run the `dwifslpreproc` data with `-rpe_all` option. This isn’t a recommendation but a requirement. `dwifslpreproc` only accepts one input image; so if your DWI data have been acquired in multiple series, there’s _no choice_ but to explicitly concatenate them together first. > Or should you extract out the b0 of primary and reverse PE and specify using `-se_epi` & `-align_seepi` options together with `-rpe_all`? This would result in identical results. If you specify `-rpe_all`, then _internally_, `dwifslpreproc` will extract the _b_=0 volumes and use those for inhomogeneity field estimation. The first volume provided to `topup` will also be the first volume provided to `eddy`, and therefore the inter-protocol motion issue is not present. By manually extracting these _b_=0 volumes and providing them via the `-se_epi` option, `dwifslpreproc` will provide the volumes that you have specified via this option to `topup`; but it’s the same data that `dwifslpreproc` would have provided to `topup` in the absence of the `-se_epi` option anyway. > Furthermore, if I should concatenate both together when running the `dwifslpreproc`, then is it advisable to run from the start the denoising correction, degibbs correction, etc all together or should these steps be done separately? For Gibbs ringing removal it doesn’t matter, since it’s a volume-wise operation. For denoising there’s been a little bit of discussion on the forum, but I don’t think that evidence has been presented with which to establish a consensus. The fundamental question here is whether or not the noise level in a particular voxel in a particular location will be equivalent between the two series. While they’re likely to be very similar, there is some chance that it may vary a little due to changes in internal scanner calibrations, parallel imaging, or severe distortions. The safer approach is to denoise each series individually. > My last question here is whether all the answers related to `dwifslpreproc` would apply the same for the older version of the command, `dwipreproc` (ie. version `3.0_RC2-117-gf098f097`)? The update from `3.0_RC2` to `3.0_RC3` was where the `-align_seepi` option was introduced. Changes from `3.0_RC3` to `3.0.0` should not affect this specific functionality. Cheers Rob --- _[View the full topic](https://community.mrtrix.org/t/dwifslpreproc-and-motion-correction/3953)._