Hi Sebastian,
Firstly, it’s important to recognise that while dwifslpreproc provides a different interface and deals with a certain amount of processing automation, it is still ultimately FSL’s topup and eddy that do the heavy lifting. Just want to make sure that you’re not judging that choice as being of greater discrepancy than it actually is.
I went and read the documentation for dwifslpreproc … I could not gather from the documentation alone or from the preprocessing tutotial I found.
There’s also this page in the documentation; admittedly it would benefit from some images, and there’s references to much older versions of MRtrix3 that could probably be removed, but figured I’d link nevertheless.
Is the value for -readout_time calculated the same way as calculated for the “acqp” file for FSL (Echo spacing x 0.001 x (EPI factor -1))?
Yes, it’s the same value. The only reason dwifslpreproc requests that value at all is because it needs to provide it to the underlying FSL tools.
The command line does not require an index file, in contrast to eddy’s command line. Why is that so?
The reason I even started writing the script that eventually because dwifslpreproc is because I noticed a lot of people failing to understand the interfaces to these commands (not because the interface is bad, but because it has to support the most general use case, and therefore the intrinsic complexity of the problem is exposed to the end user, even if their own acquisition is relatively simple) or encountering other annoying barriers to processing their data (e.g. axes with odd dimensions crashing topup). The purpose of the -rpe_* options in dwifslpreproc is to provide a small set of reasonably comprehensible multiple-choice options from which the user has to choose, and from that information combined with the image data provided as input, dwifslpreproc can internally construct e.g. the index file, thus sparing the user from the nature of those data, and allowing me to minimise the frequency with which users around me were running into problems at this stage of processing.
Later on I added the capability to infer from header metadata information the nature of the phase-encoding design of the acquisition, and therefore automatically determine the appropriate pre-processing steps to apply, via the -rpe_header option. Fully automating the pre-processing of arbitrary input DWIs makes the dwifslpreproc script quite powerful for e.g. processing BIDS data in the case when you don’t know a priori by what kind of strategy a user may have acquired the DWI data that they provide to your tool.
If dwifslpreproc were instead to necessitate that the user themselves manually construct the metadata files required by FSL’s topup and eddy and provide those manually, then that script would have little purpose for existence. Or indeed, potentially worse. The current situation, where we have an MRtrix3 command that invokes tools from software packages other than MRtrix3, is already questionable from an attribution perspective; we have taken multiple explicit steps to try to mitigate this, trying to make it very clear that it is these FSL tools that provide the primary image processing capability (and thus necessitate citation), dwifslpreproc merely provides a simplified interface for the most common acquisition strategies and performs a certain amount of processing automation. But to distribute a piece of software with your own name stamped on it, for which you provide only a small incremental addition whereas the interface and 99.9% of the code belongs to someone else, would be unethical. I only hope that others judge dwifslpreproc to be on the right side of that line.
If you’ve wrapped your head around the topup / eddy interface, and don’t mind manually performing the multiple requisite steps, and your data don’t belong to one of the scenarios that lead to issues, then you’re not missing out on anything by using the FSL commands directly rather than dwifslpreproc. It just means getting your hands a little dirtier.
Cheers
Rob