Dwifslpreproc doesn't mitigate motion

Hi all,

Hopefully you can help. As usual I have ex-vivo mouse brains that I’m working with. In this particular dataset, the brains were taken out of the skulls prior to imaging. In some of the sequences, there is downward drift of the brains in the FOV of the course of imaging (total of 214 volumes). TORTOISE corrects this motion with rigid alignment to the first b0 and the optional inclusion of quadratic modeling of the eddy currents. Those come out just fine and well-aligned across the whole 4D image.

dwifslpreproc on the other hand does not correct the drift. When there is drift, the brains are still much lower in the FoV at the end of the sequence than at the start after processing. I would strongly prefer dwifslpreproc for this pipeline but obviously the alignment is an issue. I don’t have an RPE b0 and Synb0_disco isn’t validated for mice so I can’t use TOPUP.

Any suggestions on correcting the drift? I can make an example NIFTI available if helpful.

1 Like

Hello @araikes ,
Rigid transformation can also be done using mrregister. Then, running eddy from dwifslpreproc or from FSL might be fine for eddy correction.

Again, antsRegistrationSyN.sh can also perform rigid transformation. I think registration to T1WI or T2WI can also mitigate EPI distortions if you have those images.

I hope this answers your question.

Best wishes,
Suren

Hi @suren,

Do you have an example for registering the individual DWI volumes to e.g., the initial b0 using mrregister? I know I can use mrregister to do inter-modal registration but I don’t see a good option for intra-modal registration. I suppose I could deconstruct the whole thing to do individual volume registration but that seems less ideal.

As far as ANTs registration goes, yes I can do rigid transformations as well as registration to my T2w images. However, using the mean bzero for registration doesn’t fix diffusion weighted volumes that aren’t aligned with the bzero images.

Hello @araikes ,

I think antsRegistrationSyN.sh+antsApplyTransforms or mrregister+mrtransform will be fine to register first b0 with T1 or T2WIs.

I think the antsApplyTransforms or the mrtransform can apply registration to the whole DWI series.

Best wishes,
Suren

Hi Adam,

Without going to the extent of sharing NIfTIs, just showing sagittal lightboxes across volumes, before and after pre-processing with the two packages, would probably communicate the effect pretty well.

To be clear, you’re not talking about a residual misalignment between processed data across the different shells, or a difference in the position of the motion-corrected data relative to the voxel grid, but it actually looks like subject “motion” in a particular direction as a function of time has simply not been appropriately estimated? Ultimately this is deep inside of FSL’s eddy so I’m limited in what I can suggest. If you do want to ask for help from FSL, I would suggest running eddy manually so that the reported issue is entirely dissociated from MRtrix3.

Does the direction of that progressive motion happen to coincide with the phase encoding direction? That’s what I’d think would be most likely to happen; it’s kind of like a field inhomogeneity distortion of the whole image due to scanner frequency drift (and the failure of the scanner to recalibrate such). But even if that’s the case, I’d expect eddy to attribute it to either a gradually-increasing eddy current or to subject motion. You could nevertheless try the --dont_sep_offs_move option and see what happens. Since you mentioned it in passing, eddy can also model higher-complexity eddy current distortions—see the --flm option—though I wouldn’t expect that to have an influence here. I would also check their documentation for the --niter option, since they make a suggestion there for residual motion.

Cheers
Rob