artifacts.py hmc remove b0 images

[cni-md]

I found a bug in the hcm pipeline. The pipeline removes the b0 images.

Fix for only one b0 image at the beginning: https://.com/cni-md/nipype

(GetMovingDWs extract only images with diff weighting. If we have more than one b0 image or the b=0 is not at the beginning bval/bvec will have wrong values)

I found the procedure from epi.py fieldmap_correction more suitable to coregister the warped fieldmap with the EPIs to get the transformation matrix. Is there a reason to skip this in the BMapMag2B0 part of the fmc pipeline?

No I got stocked at Shiftmap2Warping. vsm2dfm give me a 4D image (one empty volume, one with the shift map?, one empty volume) whereas the ScaleField Node has still a resonable ShiftMap.

How should the result of vsm2dfm look like?

Joerg

[oesteban]

@cni-md I'll look at it this evening. Thanks for posting!

[oesteban]

@cni-md How should the result of vsm2dfm look like?

A 4D volume with 3 timepoints, the displacements vector field corresponding to the warping. Two of them should be zero, and the timepoint corresponding with the phase-encoding direction will have the shifts, scaled to relative mm units. So it looks like it works ok in your case if the EPI is A >>> P or P >>> A.

[oesteban]

Ok, this is true. It is just the inheritance from the early workflow. I'll fix it ASAP

[oesteban]

Hi @cni-md , could you give my last commit a try and let me know before I merge it?

[cni-md]

@oesteban : yes. https://.com/oesteban/nipype.git ? which branch?

[cni-md]

@oesteban ok. now fmb is getting the right b0 image and not the first dwi. But BmapMag2B0 is not able to register. My fieldmap is shifted by 128mm but this is a different problem :(
The hmc does not look as stable as the output of create_dmri_preprocessing() I still see rotations on the y axis. Same for eddy.

[oesteban]

The hmc does not look as stable as the output of create_dmri_preprocessing() I still see rotations on the y axis. Same for eddy.

You mean that some rotations were not corrected, right?. This is a different problem, I wanted to make a robust configuration of FLIRT (https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind1409&L=fsl&D=0&P=100061) but I guess that it is not flexible enough.

A worth move would be switching from FLIRT to ANTS. But this is not a trivial change as the ITK coordinate system is LPS and affine matrices are not directly compatible.

[satra]

you could use c3d_affine_tool to go between FSL and ITK for any affine transform.

[oesteban]

I think we can merge this fix and open a new issue for migrating hmc to ANTS. Would that be ok?