Susceptibility correction using mrregister on reversed phase encoded data


I’m trying to use mrregister to correct for susceptibility artefacts (instead of using FSL’s topup). Basically I have a b0.nii.gz and a b0_rp.nii.gz (rp stands for reversed phase encoding). Both have the same voxel grid.
I then register (affine and nonlinear) the b0.nii.gz to the b0_rp.nii.gz and save the midway images:

mrregister b0.nii.gz b0_rp.nii.gz -transformed_midway midway_1.nii.gz midway_2.nii.gz -nl_warp_full full_warp.mif

The average of these midway images should give me a good approximation of the b0 corrected for susceptibility artefacts. However, they are defined on a different grid than the b0.nii.gz and b0_rp.nii.gz input images. Of course I could again regrid the output, but I want to avoid multiple interpolations. Therefore a first question: what defines the midway grid in mrregister?

Eventually my goal is to apply the full_warp to bring a dwi series to this midway space, thus correcting for the susceptibility artefact. For this I would do:

mrtransform dwi.mif dwi_corrected.mif -warp_full full_warp.mif -midway_space

This would however mean that my dwi_corrected.mif is in the same grid as the midway images (which seems to be different than the input b0s).

[update] a solution to this last issue is to regrid the full_warp.mif image to the grid of the original b0’s first, and then applying that using the above command. So at this point I’m only still wondering why the midway space has a different grid?



Dear @tbilliet,

I was wondering, what is your motivation of not using topup for this? I believe topup would do better job to separate effect of movement and B0 inhomogeneity?


Hi Antonin,

I would turn the question around: why not try it? :wink:
It’s a way to become more familiar with the different methods. If in the end topup does a better job, so be it :slightly_smiling_face:


If you do not have any other more useful task to put effort into…
But OK, educative reasons, I accept that.:upside_down_face:

I think that you would want to constrain the deformation only to the direction of the phase encoding to make it work reasonably. Not sure whether this is possible in mrregister.


I would use FSL topup unless you have specific reasons to write your own custom susceptibility correction.

mrregister and mrtransform use interpolation to determine the intensity for positions off the original grid. They do not apply intensity modulation, topup uses the determinant of the jacobian of the warps to correct for this. Therefore signal hyperintensities due to susceptibility artefacts are not corrected using mrtransform. You could do this yourself using the jacobian filter in mrfilter but besides the final output, also the registration might be affected by those hypterintense artefacts. Finally if you wanted to correct for inter- or intra-volume motion (eddy) you’d need to write your own scripts again which would likely require further interpolations if you want to stick to the tools currently available in MRtrix3.

The midway space is the coordinate grid that lies between the first and second input image to mrregister. This is to reduce bias due to different degrees of interpolation during registration. More precisely, the average space grid is calculated using the average of the (smallest possible) rotations that align the first and second input images’ scanner coordinate systems to the (unsigned) scanner coordinate system using quaternions. The midway space voxel spacing is the average of the two input images’ voxel unit vectors projected onto these new axes.


It does not exist but should be easy to implement by constraining the displacement field update after each registration step (src/registration/nonlinear.h).

We’ve actually got an internal solution that does this, but is focused on using the T1 and multi-tissue CSD outcome, in the absence of reverse phase encoded data.

It’s a bit more complicated and uses a few fancy outlier-rejection and iterative contrast optimisation mechanisms, but the basis is:

…together with the useful code that is already there in the mrregister back-end.

It’s at the bottom of the priority list currently, but I’ll write it up as a technical note or something at some point, and release a working version of it.

…or do you need an open-source and more friendly licensed version of such a tool? :wink: