DOC: Revise *dMRIPrep*'s road-map #147
Conversation
Resolves: nipreps#116.
Co-authored-by: Michael Joseph <[email protected]>
Co-authored-by: Ariel Rokem <[email protected]>
| This release will also include Salim's efforts in `#144 <https://github.com/nipreps/dmriprep/pull/144>`__ | ||
| to provide a temporary implementation of head-motion and eddy-currents correction using | ||
| FSL's ``eddy``. | ||
| This temporary solution will be replaced by our 3dSHORE-based algorithm ported from QSIPREP, |
There was a problem hiding this comment.
Can we go ahead and name it yet? I thought Eddy Motion Correction is pretty good...
|
|
||
| Version 1.0 (Targetted for September 2021) | ||
| ------------------------------------------ | ||
| Wrap-up evaluation Phase II with the first stable release of *dMRIPrep*. | ||
|
|
There was a problem hiding this comment.
I think it might be helpful to clarify that dmriprep is both dataset-adaptive (i.e. to heterogeneous acquisition/encoding schemes, available metadata) and user-configurable (i.e. providing the option to run denoising or not if associated compute cost would be too high, susceptibility distortion correction or not if the available data doesn't support it).
There was a problem hiding this comment.
user-configurable (i.e. providing the option to run denoising or not if associated compute cost would be too high, susceptibility distortion correction or not if the available data doesn't support it).
I would prefer it were not very configurable - and that requires a lot of solid heuristics. But the less human intervention, the better.
There was a problem hiding this comment.
Fair enough.
Though I think at least the former (i.e. dataset adaptive) is a key selling point since there are good reasons to think that the same steps are not optimal for all types of dMRI data...
Co-authored-by: Michael Joseph <[email protected]>
Resolves: #116.