Connectome2tck -nodes question

Hello all, I am currently trying to extract a subset of tracks from a generated structural connectivity matrix. There are 5 instances were a node is used and I would like to obtain these 5 tracks. Now when utilizing the -node option I input the node pairs as a comma-separated list. However, the generated track file only has 4 total streamlines instead of the 5 indicated in the -node options. An image of usage and tckinfo verification is below. Thank you for any insight on the matter.

Love and Peace,

Ricardo

Hey Ricardo,

It seems to me that, if you know from your connectivity matrix that there are 5 tracks assigned to a specific node of interest, it is unusual that you would provide multiple node indices via the -nodes option and then use -exclusive. You have specified more than 6 nodes, so at least some of the nodes you have specified are not connected to your node of interest. Moreover, this usage would include in the track file output any streamlines that are assigned to two nodes in this list that are not your node of interest, and if you failed to include or mis-typed a specific node in this list, that could result in the omission of an otherwise desired streamline. So this usage seems to introduce a lot of scope for errors.

I think from your description all you want to do is provide just your one node of interest via the -nodes option, not use the -exclusive option, but still use “-files single”.

Rob

Ah so, the issue is the use of the -exclusive function. After re-reading the description of this option I can see why this was the cause of the error. Thank you.

So my other question now is if I would have to manually input this comma-separated list when using this -nodes option. Say I have 20 node sets of interest, I have the list. Is there a way to consolidate this list and use it for the -nodes option (i.e. -nodes file_name_containing_nodes) or would I have to give it all 20 node sets (i.e. -nodes 1,2, 1,3, 1,5, etc.) ? Hopefully, this question makes sense.

Thanks,

Ricardo

So my other question now is if I would have to manually input this comma-separated list when using this -nodes option. Say I have 20 node sets of interest, I have the list. Is there a way to consolidate this list and use it for the -nodes option (i.e. -nodes file_name_containing_nodes) or would I have to give it all 20 node sets (i.e. -nodes 1,2, 1,3, 1,5, etc.) ?

  1. You can do this without relying on MRtrix3 capabilities, just using shell features. If text file “nodes.txt” contains the node indices of interest, do:

    connectome2tck ... -nodes $(cat nodes.txt) ...
    

    Just make sure that the contents of that file doesn’t include any spaces, and doesn’t have a newline at the end. All it’s doing is having the shell run the “cat” command and dump the contents of that file into the connectome2tck command invocation string before it’s even run.

  2. " -nodes 1,2, 1,3, 1,5, etc." is not a list of nodes; that’s a list of edges. That usage also wouldn’t work, since string “1,2” would be interpreted as the input to the -nodes option, and “1,3” and “1,5” would be interpreted as input arguments to the connectome2tck command, resulting in an immediate and slightly cryptic error.

    The comma-separated list provided to the -nodes option should only contain each unique node index once (e.g. “-nodes 1,2,3,5”). If there are certain connections in which you are not interested (e.g. you want 1-2 and 1-3 but not 2-3), just allow the command to generate one track file for each edge, and then delete the resulting track files that you don’t want.

Rob

2 Likes

I apologize for the wrong terminology, thank you for clearing that up it’ll help in the long run for sure as i go through this research process. Additionally thank you for the insight on how to go about executing the implementation of a lot of edges into the command. Will this method (e.g. -nodes 1,2,3,5) work for instances where the streamline is coming from say 1 to 2 and then from 3 to 1, as in will this usage take into account streamlines coming from and going to edge 1? Thank you for your time and insight.

Ricardo

Will this method (e.g. -nodes 1,2,3,5) work for instances where the streamline is coming from say 1 to 2 and then from 3 to 1, as in will this usage take into account streamlines coming from and going to edge 1?

connectome2tck is entirely direction-agnostic. In the rare instances where MRtrix3 treats diffusion-based data in a non-symmetrical way - including streamlines - it should be pretty explicit about such. Outside of those rare instances, everything should be assumed antipodally symmetric / undirected / etc…

Gotcha, thank you so much for the insight. So would it be fair to assume that the subset of tracts produced by this function, connectome2tck, that is generated by utilizing the -node option will produce tracts that are in essence all connected to the initial value of the edges provided (i.e. in the case above 1) or does a produce a subset of tracts that all share connections amongst all the edges provided – i.e. all of the tracts produced have the possibility of either starting or terminating (keeping in mind this is all direction-agnostic) at the edge labeled 1. I hope that made sense, if not I can provide an example.

So would it be fair to assume that the subset of tracts produced by this function, connectome2tck, that is generated by utilizing the -node option will produce tracts that are in essence all connected to the initial value of the edges provided (i.e. in the case above 1)

If I understand the phrasing here, then no, that’s not the case. The first entry in the list provided to the -nodes is not treated any differently to any other entry in the list.

or does a produce a subset of tracts that all share connections amongst all the edges provided – i.e. all of the tracts produced have the possibility of either starting or terminating (keeping in mind this is all direction-agnostic) at the edge labeled 1.

Firstly I presume you mean the node labelled 1, not the edge?

Secondly, this depends on the presence or absence of the -exclusive option.


Maybe a worked example might work here. Let’s ignore the operation of the -files option here - so the default behaviour of one file per edge will be used - and focus purely on -nodes and -exclusive. Let’s say the parcellation image has 4 nodes. Under default operation, the command will produce the following files:

tracks1-2.tck
tracks1-3.tck
tracks1-4.tck
tracks2-3.tck
tracks2-4.tck
tracks3-4.tck

The direction-agnostic nature of the process means that streamlines in file tracks1-2.tck may start at node 1 and end at node 2, or start at node 2 and end at node 1; furthermore, there is no file tracks2-1.tck.

This is what we get if we run the command with the option -nodes 1,2:

tracks1-2.tck
tracks1-3.tck
tracks1-4.tck
tracks2-3.tck
tracks2-4.tck

All edges involving node 1 are saved, and all edges involving node 2 are saved. The only edge excluded from the output is that between nodes 3 and 4: neither node appears in the list of nodes of interest.

This is what we get if we run the command with the option -nodes 1,2,3 -exclusive:

tracks1-2.tck
tracks1-3.tck
tracks2-3.tck

Only those edges for which both nodes appear in the list of nodes of interest are included.


Hope that makes sense? This is the interface that I determined at the time would provide sufficient power to handle the majority of use cases without being overly complex; it can just take a moment to wrap your head around.

Plus, you can always just generate all such files and then delete all the ones you don’t want :man_shrugging:

Rob

example:
All edges involving node 1 are saved, and all edges involving node 2 are saved. The only edge excluded from the output is that between nodes 3 and 4: neither node appears in the list of nodes of interest.

This is what we get if we run the command with the option -nodes 1,2,3 -exclusive :

Yes this makes sense, so there is no way right off the back to just get the only the following given your example and none of the other extra .tcks?
tracks1-2.tck
tracks1-3.tck

there is no way right off the back to just get the only the following given your example and none of the other extra .tcks?

tracks1-2.tck
tracks1-3.tck

Correct. I don’t see any “general” command-line interface that would make the extraction of just those edges of interest any easier than just specifying “-nodes 1” (without “-exclusive”), and then deleting tracks1-4.tck from the filesystem. The interface to this command causes enough headaches as it stands now…