[STORY] Pydarfy different tools to do multimodal registration

[arkiev]

This story stems from this post https://github.com/MRtrix3/mrtrix3/issues/2474

DWI registration (and subsequent transformation) to T1 space is an important step in connectomics. There are a number of different tools available to complete this step. We want to provide the user with an array of tools that can be used to do the registration (and transformation), and thereby allow the user to select the registration tool.

Here are some possible algorithms:

• [x] Basic flirt, using mean b=0 image by default
• [x] epi_reg, maybe by default using FreesSurfer or FastSurfer outputs
• [ ] Rob's technique in MRtrix3_connectome based on the INVERSE method (generate pseudo-T1w from DWI mean b=0 using histogram matching and register to T1w; then same in other direction, ie. generate pseudo-b=0 image based on T1w and register to DWI mean b=0; average the two transforms)
• [ ] Generic wrapper for ANTs (see this post for example usage)
• [ ] combination of FreeSurfer and ANTs (see here )

Ideally, since we are moving DWI to T1 space, we will need to also rotate the bvec along with the DWI. This can be done using mrtransform. So, it makes sense to convert the transformation matrix to mrtrix3 format (using transformconvert and apply the transform using mrtrix3 tools (where possible).

[Lestropie]

• For the MRtrix3_connectome approach, given the introduction of multi-contrast registration into MRtrix3, it should be possible to, rather than performing two registrations and averaging the result, instead provide both image pairs as inputs to a single mrregister invocation, which will consider image data from both contrasts (T1w-to-pseudo-T1w and pseudo-b=0-to-b=0) in its calculations. Would however need to verify whether gross differences in image intensities between the two contrasts may bias the results to be driven primarily by one contrast rather than both.
• If you have a gradient table in FSL format, and apply a rigid body transformation to the whole series, then no modification of the gradient table is required: the directions are defined with respect to the scanner axes, and so undergo the same rotation as the image itself. The problem only arises if one has directions defined with respect to real space, and then rotates the image data but not the directions. Ie. If you have a NIfTI with bvecs / bvals, then do a conversion to MRtrix format -> mrtransform -linear -> convert back to NIfTI with bvecs / bvals, you should see that there is zero net effect on the contents of the bvecs file.