Warping tck files using FLIRT (fsl)

[jdtournier]

Hi Eloy,

A lot of things going here, I’ll try to respond to a few issues as I come across them - not all of them have anything to do with the problem at hand:

@eloydelas

We have tried to realign the tck file into structural image with the same way we did before the upgrade.

Probably none of my business, but can I just check why you need to do this? You could simply coregister the T1 to the diffusion data, at which point the tracks should overlay with the T1 just as well? Maybe you have a particular application that requires the T1 be in a particular space? But if all you’re after is the ability to overlay the tracks on the T1, then aligning the T1 to the diffusion is the simplest way to achieve this.

@eloydelas

3. Apply spatial transformations to an image:
   for i in 0 1 2;do
   fslchfiletype NIFTI_GZ flirt-{i} mrtransform flirt-{i}.nii.gz -linear inv_epi2struct.mrtrix flirt2tck-${i}.nii.gz -template T1_image -inverse -half -grad encoding.b
   done

• You shouldn’t need to change the fslchfiletype command here, MRtrix3 will accept *.nii files as-is anyway.

• mrtransform can take the 3 warp images in one go using the square bracket syntax, which means it treats the 3 images as a single 4D image. You’d then only need one call to mrtransform rather than 3.

• I agree with @maxpietsch that you shouldn’t need the -half option here - that will definitely give you the wrong transformation.

• You also don’t need the -grad encoding.b option, that will insert the DW scheme into the header for the transform images - which makes little sense. Regardless, the output is produced in NIfTI format, which can’t actually store that information anyway…

• so this should mean you can write the above for loop as a single command:

    mrtransform flirt-[].nii -linear inv_epi2struct.mrtrix flirt2tck.mif -template T1_image -inverse
  

@eloydelas

4. warpcorrect flirt2tck-.nii.gz flirt2tck.mif

The only purpose of warpcorrect is to remove unwanted zeros that other registration packages might write in places where the target voxel has no correspondence in the original image (i.e. it maps to a point outside the FoV). The relevant MRtrix3 commands should write a NaN to indicate this, so shouldn’t need special handling - let us know if that’s not the case.

Finally, by using the -template option to mrconvert, the images will be regridded, which might be unnecessary, assuming this is a rigid-body linear transform: in this case only the transform matrix in the header needs to be modified. You’d be better off removing the -template T1_image option here.

@eloydelas

We have used the library: 3.2.0

That might be a problem - I’m not sure. I seem to recall that MRtrix3 wouldn’t even compile with anything older the Eigen 3.2.4 or so, so I’m surprised to hear that you’d even be able to use an older version…? In any case, I’d recommend updating to the current stable 3.2.9 version if you can - although I doubt this will sort out this issue: if there was a problem, I’d expect it wouldn’t even compile, crash at runtime, or produce outright garbage…

@eloydelas

We follow the same procedure with the previous version with optimal results.

Can I check exactly what you mean by ‘the previous version’ here? Was this working with MRtrix3 before? Is there any way you can pinpoint the version that worked before? For example by running mrinfo on a *.mif image produced by the version of the software that worked before (the version of MRtrix3 used to generate the image is written in the header nowadays).

@eloydelas

We do not understand why the coregister with tck file is suboptimal.

Not sure I do either… But assuming everything in MRtrix3 is actually working properly (not a given if you say these exact commands used to work fine…), then it’s worth emphasising how easy it is to get confused as to whether you need the transform or its inverse - see this post for details. What you need is the forward transform from DWI to T1, which is typically the inverse of the transform you’d use to warp the DWI to T1 space. One way to check that you’re using the right transform is to apply the same transformation to the T1 as you did to the initial warps you generated from it:

mrtransform T1_image -linear inv_epi2struct.mrtrix T1_image_coreg.mif -inverse

If the resulting T1_image_coreg.mif is aligned with the DWI and the tracks overlay onto it properly, then all should be fine - you should be able to run the tcknormalise command with your flirt2tck.mif. If that’s not the case, then try removing the -inverse option, or using the inverse matrix in the first place.

If that doesn’t fix it, then I’m not sure. I haven’t looked at your ANTS scripts too closely, so I’m not sure what the issue might be in this case, but there’s very little that I can think of that would explain what you’re showing other than simply having used the inverse transformation instead of the forward one…