tck2connectome

[AndrewZalesky]

I have added a matlab folder and included a matlab version of tck2connectome. It reads in the streamline endpoints in half precision as an npy file as well as the parcellation atlas. At the moment, it only outputs streamline counts, but I can modify to take in weights for each streamline.

Sina - the agreement is very close to the matrix that you provided to us as an example (correlation = 1.000); however I have noticed some tiny differences for particular pairs of regions. This may be due to subtle differences in the way that the radial search is implemented. Not sure how to best reconcile these differences. Have you implemented your own version of the radial search? Perhaps we can compare? Andrew

[sina-mansour]

For the results that I shared, the matrices were directly generated by mrtrix.

But I'm also finalizing a python script that accomplishes the same thing. For the radial search, what I'm doing is:

• I first build a KD tree data structure to store the 3d coordinates of every voxel (extracted by the affine transformation of the grid) that is labeled by the atlas as a region (the label is not zero).
• Next, I query the KD tree with a list of coordinates from all streamline endpoints. The queries provide the information about (i) the closest voxel in the KD tree (ii) the distance between the endpoint and the closest voxel.
• Finally, I filter the streamlines that have a distance smaller than the defined threshold and add them to the appropriate element of the connectivity matrix.

The KD tree was used to maximize query performance. I'll post a comment here once I've added this python script to the repository.

That being said, I think the observed small differences may actually be due to minor implementation differences, but as long as the final matrices are mostly similar (as you mentioned a correlation of 1.000) the tiny differences should not cause any serious problems. We could also check the absolute difference of the matrices to see what proportion of streamlines are assigned differently.

[AndrewZalesky]

Hi Sina,

sounds like an interesting approach! Might be more efficient than my implementation, which takes about 3 minutes for the example NPY endpoint file that you sent through.

I think that your approach would need the tree to be recomputed for each individual, given that atlas voxels can vary between individuals?

Do you round streamline endpoints to voxels coordinates for the sake of computing distances? I assume that the tree only stores information for voxel corrdinates, but not the precise non-integer endpoint coordinates. Perhaps this may account for the subtle variation.

Andrew

On 23/03/2022 3:32 pm, Sina Mansour L. wrote:

For the results that I shared, the matrices were directly generated by mrtrix.

But I'm also finalizing a python script that accomplishes the same thing. For the radial search, what I'm doing is:

• I first build a KD tree data structure to store the 3d coordinates of every voxel (extracted by the affine transformation of the grid) that is labeled by the atlas as a region (the label is not zero).
• Next, I query the KD tree with a list of coordinates from all streamline endpoints. The queries provide the information about (i) the closest voxel in the KD tree (ii) the distance between the endpoint and the closest voxel.
• Finally, I filter the streamlines that have a distance smaller than the defined threshold and add them to the appropriate element of the connectivity matrix.

The KD tree was used to maximize query performance. I'll post a comment here once I've added this python script to the repository.

That being said, I think the observed small differences may actually be due to minor implementation differences, but as long as the final matrices are mostly similar (as you mentioned a correlation of 1.000) the tiny differences should not cause any serious problems. We could also check the absolute difference of the matrices to see what proportion of streamlines are assigned differently.

— Reply to this email directly, view it on GitHub https://github.com/sina-mansour/UKB-connectomics/issues/30#issuecomment-1075904320, or unsubscribe https://github.com/notifications/unsubscribe-auth/ANXR7AWPWRRJ27CSEKUOU73VBKNFNANCNFSM5RFAINUA. You are receiving this because you authored the thread.Message ID: @.***>

[sina-mansour]

Hi Andrew,

Yes, the tree is reconstructed for every individual's atlas. But it takes only a few seconds if I remember correctly.

The streamline endpoints aren't rounded, but the voxel indices are transformed to mm space using the affine before tree construction. So the tree only stores voxel coordinates in mm space. The precise non-integer endpoint coordinates are then directly queried against the tree. This is the package that handles these queries.

Anyhow, the connectomes that I had shared were created with mrtrix's tck2connectome so the subtle variations may be due to how mrtrix does things differently compared to the matlab code. I'll make sure to check the differences of connectomes mapped with my script, and mrtrix's tck2connectome.

But I reckon if the correlations are nearly perfect, then the impact shouldn't be too severe.

Sina

[AndrewZalesky]

Thanks Sina.

Yes - I understand your approach now after you explained it to me today. It would be nice to compare matrices once you run your approach on the example data.

best,

Andrew

On 24/03/2022 1:25 pm, Sina Mansour L. wrote:

Hi Andrew,

Yes, the tree is reconstructed for every individual's atlas. But it takes only a few seconds if I remember correctly.

The streamline endpoints aren't rounded, but the voxel indices are transformed to mm space using the affine before tree construction. So the tree only stores voxel coordinates in mm space. The precise non-integer endpoint coordinates are then directly queried against the tree. This https://docs.scipy.org/doc/scipy/reference/generated/scipy.spatial.KDTree.html is the package that handles these queries https://docs.scipy.org/doc/scipy/reference/generated/scipy.spatial.KDTree.query.html#scipy.spatial.KDTree.query.

Anyhow, the connectomes that I had shared were created with mrtrix's tck2connectome so the subtle variations may be due to how mrtrix does things differently compared to the matlab code. I'll make sure to check the differences of connectomes mapped with my script, and mrtrix's tck2connectome.

Sina

— Reply to this email directly, view it on GitHub https://github.com/sina-mansour/UKB-connectomics/issues/30#issuecomment-1077002410, or unsubscribe https://github.com/notifications/unsubscribe-auth/ANXR7AQ5K3O7PUQQLMDU543VBPHCPANCNFSM5RFAINUA. You are receiving this because you authored the thread.Message ID: @.***>

[sina-mansour]

Hi Andrew,

I've just added my python implementation of tck2connectome to the repository. (It takes ~7 seconds to execute)

I also get a near perfect correlation with MRtrix's connectomes, but there are a few streamlines for which the solution is not exactly the same. (correlation: 0.99999966)

We could potentially check and compare the mappings to find what makes the difference.

Best, Sina

[AndrewZalesky]

That's great Sina - much faster than my implementation. I will work on speeding up my code.

I think it would be helpful to understand the source of these subtle differences. The algorithm is completely deterministic (unless an endpoint resides at the corner of a voxel) and we should be able to track down the differences. Would it be possible to generate a list linking each streamline to a node pair so that we can identify where the radial search implementations yield different assignments?

This is certainly not urgent.

Andrew

On 28/03/2022 7:55 pm, Sina Mansour L. wrote:

Hi Andrew,

I've just added my python implementation of tck2connectome https://github.com/sina-mansour/UKB-connectomics/commit/88a4123b37a7abf693af22729a37a333381b0566#diff-47a411f6dafc5ca36f8462e84793677e53ccb1ae7f56e89b4ae3d442119fbbab to the repository. (It takes ~7 seconds to execute)

I also get a near perfect correlation with MRtrix's connectomes, but there are a few streamlines for which the solution is not exactly the same. (correlation: |0.99999966|)

We could potentially check and compare the mappings to find what makes the difference.

Best, Sina

— Reply to this email directly, view it on GitHub https://github.com/sina-mansour/UKB-connectomics/issues/30#issuecomment-1080374622, or unsubscribe https://github.com/notifications/unsubscribe-auth/ANXR7AUJN26YXPIWARJJZIDVCFXXFANCNFSM5RFAINUA. You are receiving this because you authored the thread.Message ID: @.***>