Tck2connectome different outputs

Dear experts,

I’ve run the same command to generate the connectomes:

tck2connectome tracts.tck Labels.nii.gz con_NOS.csv -zero_diagonal -symmetric -tck_weights_in weights-SIFT2.txt

Using 3 different versions of the software:

MRtrix 3.0_RC3-15-g9494da8d 
MRtrix 3.0.2-22-ga487feef
MRtrix 3Tissue_v5.2.8

For my surprise, I found different results for each version (using the command diff in Ubuntu), is it this known? I assume is a numerical difference handling the weights, but just to be sure…

Best regards,

Manuel

Hi,

An update to this, I’ve seen that the default values for the local search changed. When in the last version I modify it and use as a value 2 mm, I obtain the same connectomes with the versions MRtrix 3.0.2-22-ga487feef and MRtrix 3Tissue_v5.2.8, but still slightly different than from the version MRtrix 3.0_RC3-15-g9494da8d. It is possible that the implementation of the local search is slightly different? Thanks in advance.

Best regards,

Manuel

A quick look through the history shows this change to the radial search distance from 2mm to 4mm, on 21 April 2020, which was made it as part of 3.0.0, and hasn’t been touched since. So that would explain the discrepancy between 3.0.2 and 3.0_RC3.

As to the difference for the 3Tissue version, I’m not sure. It’s basically what our dev branch looked like at the time it was forked, with a few minor changes – and as you can see from the diff, none of those changes relate to any of that code. It should behave more or less the same as 3.0_RC3_latest, tagged on 11 September 2019. Note that there have been quite a few changes to the code since the 3Tissue fork (last common commit is this one in May 2019), and any of the changes to the relevant code since then could be responsible for these differences…

Hi @jdtournier,

A quick look through the history shows this change to the radial search distance from 2mm to 4mm, on 21 April 2020, which was made it as part of 3.0.0, and hasn’t been touched since. So that would explain the discrepancy between 3.0.2 and 3.0_RC3 .

After adding the flag -assignment_radial_search 2 to the 3.0.2 the difference between 3.0.2 and 3.0_RC3 still exists (reduced, but still are some different values in the matrix). With the diff command is really difficult to see where these differences occur, so I loaded in matlab and subtracted one to another.

However, by adding the mentioned flag to the 3.0.2 version, the difference between 3.0.2 and 3Tissue is gone.

Best regards,

Manuel

After adding the flag -assignment_radial_search 2 to the 3.0.2 the difference between 3.0.2 and 3.0_RC3 still exists

I don’t personally recall any details that would lead to a difference here over and above the change to the default maximal distance in the radial search. However if you’re really determined to isolate the difference, the solution is to use git bisect.

Hi @rsmith,

Thanks for your reply. Sorry, I don’t know how to use git bisect. I’ve been doing more experiments with this and even adding the flag -assignment_end_voxels and removing the -tck_weights_in. There are still some differences between the 3.0.2 and 3.0_RC3 versions.

To be clear, the command line is:

tck2connectome tracts.tck Labels.nii.gz CON.csv -zero_diagonal -symmetric -assignment_end_voxels

The only difference between the two runs is the MRtrix version used.

It could be a small difference in the libraries converting the data from nifti to mif or handling the floating-point type data? Does this make sense?

Best regards,

Manuel

In the absence of any reasonable hypothesis to pursue, git bisect is the tool that I would myself be using if I had encountered this problem myself. Its purpose is precisely to find in a data-driven fashion the change in between two versions of code that causes the change in outcome. I’ve only used it once or twice myself, it’s not overly difficult. I was mostly hoping that you would go through the exercise yourself rather than me having to request data and do all the recompilation and testing myself :sweat_smile: But if you’re not confident, bundle up and send me the data that produces the issue.

Hi,

I think I’ve found the problem. I was passing the nodes as a nifti image, however, when I convert it to mif:

mrconvert NODES.nii.gz NODES.mif -datatype uint32

And I use the NODES.mif to create the connectome, now both are identical. Also when running the same command of tck2connectome using the .nii or the .mif the results are different (using the same version of tck2connectome). It could be this the issue? how tck2connectome handles the nifti images?

Sorry, I’m to confident with git, I’ll send you the data. Thanks in advance.

Best regards,

Manuel

Well, this is entirely as expected. tck2connectome is entirely agnostic to the image format, that’s all handled via the MRtrix3 back end libraries.

If what you’re saying is that, once the maximal search distance is forced:

  • Using a .mif image, 3.0_RC3 and 3.0.2 give the same result;
  • Using a NIfTI image, 3.0_RC3 and 3.0.2 give different results;

, then my primary hypothesis would be the change in NIfTI transform handling. Where the qform and sform are both provided, but don’t provide exactly the same transform (even if only due to numerical precision issues with qform, those two software versions will (if left to their respective defaults) choose differently. However in both cases you should be receiving a warning at the command-line that this is occurring.

Basically the effect of this is that between the two softwares, the orientation of the voxel grid of the parcellation image will differ slightly; the two differing interpretations of that same image across software versions will be indiscernible at the image origin, but at the opposite corner they won’t quite overlap with one another. However the magnitude of the difference will be very small, way less than an image voxel. So it’s only in rare cases with a streamline terminating right in between two parcels that the two different software versions may assign the streamline differently.

Rob

Hi @rsmith,

This is what surprised me the most, I didn’t see any Warning at all, could be that the difference was smaller than the threshold for the warning but still enough to affect the connectome construction?

Yes, the difference was small, I just wanted to understand the reason for it.

Best regards,

Manuel