# Tck2connectome different outputs

**URL:** <https://community.mrtrix.org/t/tck2connectome-different-outputs/4328>\
**Category:** Uncategorized\
**Created:** [November 27, 2020, 9:23pm UTC](https://community.mrtrix.org/t/tck2connectome-different-outputs/4328 "2020-11-27T21:23:46Z")\
**Posts on this page:** 10\
**Page:** 1

<div class="post-metadata">

**Author:** ![mblesac](https://community.mrtrix.org/user_avatar/community.mrtrix.org/mblesac/32/2210_2.png) [@mblesac](https://community.mrtrix.org/u/mblesac)\
**Post date:** [November 27, 2020, 9:23pm UTC](https://community.mrtrix.org/t/tck2connectome-different-outputs/4328/1 "2020-11-27T21:23:46Z")

</div>

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:

```auto
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

---

<div class="post-metadata">

**Author:** ![mblesac](https://community.mrtrix.org/user_avatar/community.mrtrix.org/mblesac/32/2210_2.png) [@mblesac](https://community.mrtrix.org/u/mblesac)\
**Post date:** [December 1, 2020, 1:36pm UTC](https://community.mrtrix.org/t/tck2connectome-different-outputs/4328/2 "2020-12-01T13:36:17Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![jdtournier](https://community.mrtrix.org/user_avatar/community.mrtrix.org/jdtournier/32/2594_2.png) [@jdtournier](https://community.mrtrix.org/u/jdtournier)\
**Post date:** [December 1, 2020, 3:25pm UTC](https://community.mrtrix.org/t/tck2connectome-different-outputs/4328/3 "2020-12-01T15:25:58Z")

</div>

A quick look through the history shows this [change to the radial search distance from 2mm to 4mm](https://github.com/MRtrix3/mrtrix3/commit/7e183b4592749437997545941e64fdcba5476a0e#diff-551f40138914fa4151f38b02174420dc2fb9c0b8ce87fd0f18b38687efab06a9), 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](https://github.com/MRtrix3/mrtrix3/compare/master...3Tissue:master), 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](https://github.com/MRtrix3/mrtrix3/commit/dfda38fd25124b3dbb716d4f82c75150e0946ece)), and any of the [changes to the relevant code](https://github.com/MRtrix3/mrtrix3/commits/master/src/dwi/tractography/connectome) since then could be responsible for these differences…

---

<div class="post-metadata">

**Author:** ![mblesac](https://community.mrtrix.org/user_avatar/community.mrtrix.org/mblesac/32/2210_2.png) [@mblesac](https://community.mrtrix.org/u/mblesac)\
**Post date:** [December 1, 2020, 5:09pm UTC](https://community.mrtrix.org/t/tck2connectome-different-outputs/4328/4 "2020-12-01T17:09:43Z")

</div>

Hi @jdtournier,

> A quick look through the history shows this [change to the radial search distance from 2mm to 4mm](https://github.com/MRtrix3/mrtrix3/commit/7e183b4592749437997545941e64fdcba5476a0e#diff-551f40138914fa4151f38b02174420dc2fb9c0b8ce87fd0f18b38687efab06a9), 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

---

<div class="post-metadata">

**Author:** ![rsmith](https://community.mrtrix.org/user_avatar/community.mrtrix.org/rsmith/32/2672_2.png) [@rsmith](https://community.mrtrix.org/u/rsmith)\
**Post date:** [December 10, 2020, 12:39pm UTC](https://community.mrtrix.org/t/tck2connectome-different-outputs/4328/5 "2020-12-10T12:39:18Z")

</div>

> 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`](https://git-scm.com/docs/git-bisect).

---

<div class="post-metadata">

**Author:** ![mblesac](https://community.mrtrix.org/user_avatar/community.mrtrix.org/mblesac/32/2210_2.png) [@mblesac](https://community.mrtrix.org/u/mblesac)\
**Post date:** [December 10, 2020, 7:32pm UTC](https://community.mrtrix.org/t/tck2connectome-different-outputs/4328/6 "2020-12-10T19:32:35Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![rsmith](https://community.mrtrix.org/user_avatar/community.mrtrix.org/rsmith/32/2672_2.png) [@rsmith](https://community.mrtrix.org/u/rsmith)\
**Post date:** [January 20, 2021, 1:42am UTC](https://community.mrtrix.org/t/tck2connectome-different-outputs/4328/7 "2021-01-20T01:42:57Z")

</div>

> [@mblesac](#):
>
> Sorry, I don’t know how to use git bisect.  
> 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?

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 😅 But if you’re not confident, bundle up and send me the data that produces the issue.

---

<div class="post-metadata">

**Author:** ![mblesac](https://community.mrtrix.org/user_avatar/community.mrtrix.org/mblesac/32/2210_2.png) [@mblesac](https://community.mrtrix.org/u/mblesac)\
**Post date:** [January 20, 2021, 10:08am UTC](https://community.mrtrix.org/t/tck2connectome-different-outputs/4328/8 "2021-01-20T10:08:03Z")

</div>

Hi,

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

```auto
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

---

<div class="post-metadata">

**Author:** ![rsmith](https://community.mrtrix.org/user_avatar/community.mrtrix.org/rsmith/32/2672_2.png) [@rsmith](https://community.mrtrix.org/u/rsmith)\
**Post date:** [January 25, 2021, 12:11am UTC](https://community.mrtrix.org/t/tck2connectome-different-outputs/4328/9 "2021-01-25T00:11:24Z")

</div>

> [@mblesac](#):
>
> I was passing the nodes as a nifti image, however, when I convert it to mif … and I use the `NODES.mif` to create the connectome, now both are identical. … how `tck2connectome` handles the nifti images?

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

---

<div class="post-metadata">

**Author:** ![mblesac](https://community.mrtrix.org/user_avatar/community.mrtrix.org/mblesac/32/2210_2.png) [@mblesac](https://community.mrtrix.org/u/mblesac)\
**Post date:** [February 5, 2021, 5:09pm UTC](https://community.mrtrix.org/t/tck2connectome-different-outputs/4328/10 "2021-02-05T17:09:05Z")

</div>

Hi @rsmith,

> [@rsmith](#):
>
> However in both cases you should be receiving a warning at the command-line that this is occurring.

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?

> [@rsmith](#):
>
> 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.

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

Best regards,

Manuel