After reading this thread, I tried warping some HCP track files to MNI using the following commands:
warpconvert standard2acpc_dc.nii.gz displacement2deformation warp_subj2MNI.nii.gz
tcktransform 500K.tck warp_subj2MNI.nii.gz 500K_mni.tck
tckmap 500K_mni.tck 500K_mni_tdi.nii.gz -template T1w_restore.nii.gz
fslmaths T1w_restore.nii.gz -mul 0 add 500K_mni_tdi.nii.gz 500K_mni_tdi.nii.gz
(note: last line needed because tckmap doesn’t create the proper nifti headers)
The resulting tdi file looks like this:
You can see that it’s squished, but only on the x axis! I saw in this thread that there was a possible ambiguity with mm vs voxel offsets requiring explicit scaling, but I don’t understand how this can affect only 1 axis?
I found that if I mirror the x axis and then scale it by 1.25, the result nearly matches MNI.
mrconvert standard2acpc_dc.nii.gz tmp-.nii
mv tmp-0.nii x.nii
mrcalc x.nii -neg 1.25 -mult tmp-0.nii
warpconvert tmp-.nii displacement2deformation warp.nii
tcktransform 500K.tck warp.nii 500K_mni.tck
(including underlay T1 in case it’s possible to toggle between these two and see the subtle shift)
1.25 is the resolution of the diffusion data (though the subject-space T1 image upon which the standard2acpc_dc warp file is based is 0.7mm). However, I still notice a subtle offset, so that combined with the general weirdness of only the x-axis being scaled, and I’m not convinced this is correct.
Any idea what might be going on so that I can be more confident in the output?
Hard to tell; whenever registration / transformation is incorrect, the number of variables is grossly larger than the data available to assess the fault.
Firstly though, I would note that running
tcktransform using image “
warp_subj2MNI.nii.gz” is likely incorrect. For transforming image data, a “pull” field is used: for each voxel location in the target image space, the image data specify the location in the source image space from which image intensities should be sampled. For track data, you need the opposite, a “push” field: underneath each streamline vertex you need the new spatial location to which that vertex should be moved. Pragmatically, this means using the inverse of the “subject to MNI” warp in order to transform streamlines data from subject space to MNI space.
Given this potential additional source of error, I would suggest breaking the problem into two parts:
Make sure that you can utilise the available data correctly in order to transform image data from HCP to MNI space.
Once you have that working as expected, now try handling streamlines data.
Thanks for the reply.
I think I’ve got the directionality right, though I named the converted warp file ambiguously. “warp_subj2MNI.nii.gz” is created from “standard2acpc_dc.nii.gz” which is used for converting .nii volumes from MNI->Diffusion.
So unless I’m missing something, it still doesn’t make sense why I’m getting scaling mismatch along one axis and not the others.
I’d second that. In particular, start with warping an image using
mrtransform using the deformation field and
applywarp using the original warp (using the same reference target grid). Are both transformed images aligned?
If these match, is
500K_mni.tck aligned properly with the target space?
If so, is
500K_mni_tdi.nii.gz aligned with
OK it’s been a while but I’m looking into this issue again. I think I resolved the problem but wanted to update this post in case somebody else encounters the same thing. It’s a little confusing why this is the specific symptom, but if you swap the x-axis of the transform before applying, the x-axis shrinking no longer occurs:
mrconvert standard2acpc_dc.nii.gz tmp-.nii -force
mv tmp-0.nii x.nii
mrcalc x.nii -neg tmp-0.nii -force
warpconvert tmp-.nii displacement2deformation mni2acpc_mrtrix.nii.gz -force
rm x.nii tmp-?.nii
tcktransform mytracks.tck mni2acpc_mrtrix.nii.gz mytracks_mni.tck -force