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 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. 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
dwifslpreprocbased 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 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_seepioptions.
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 are valid.
… to verify further on
-rpe_all, MRtrix doc recommends to concatenate the primary and reverse phase DWI data together and run thedwifslpreprocdata with-rpe_alloption.
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_seepioptions 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
dwifslpreprocwould apply the same for the older version of the command,dwipreproc(ie. version3.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