So I next wanted to output a connectome assignment of each streamline using tck2connectome tracks_2_million_sift.tck association_template_mask.mif connectome.csv -out_assignment assign_connectome.csv
followed by… connectome2tck -keep_self tracks_2_million_sift.tck assign_connectome.csv connec
The problem is that the size of the output “connec” is only 692bytes and when I try to view it on mrview the tracts do not show. I tried to output this connectome using my MacBook Pro with 8GB of RAM, however when I ran it on another computer the file size was bigger and the tracts could be viewed on mrview. Is there any potential answer as to why it cannot show on my device?
, do you mean a parcellation image; i.e. an image with integer type containing non-negative values, where each unique value corresponds to a specific region of interest? Just need to make sure that the commands are being provided with the expected input data before attempting downstream diagnoses.
Rather than trying to diagnose based on the final output, I would suggest first looking at the contents of file assign_connectome.csv. This should contain two integer values per row, corresponding to the two parcels to which each streamline was assigned, and the number of rows in the file should be equal to the number of streamlines in the tractogram. If generation of this file is somehow erroneous, e.g. it contains all zeroes, then there is no point assessing the output of connectome2tck as you would in that case not have valid input data to provide to it.
Moreover, if your usage of connectome2tck is accurate:
, then there shouldn’t actually be any file called “connec”; instead there should be a large number of files generated - one for each edge in the connectome - all of which begin with “connec” and end with “.tck”.
As to why it might work on one system and not another, neither of these commands are highly demanding in terms of RAM usage or storage requirements, so I would need to know that the usage and input data are indeed precisely equivalent between the two systems, using precisely the same version of MRtrix3, before investigating such further.
Hi @rsmith - I can reply to these questions as @yanadim2 is working with me on this one.
do you mean a parcellation image;
yes this is a binarised functional connectivity map
I would suggest first looking at the contents of file assign_connectome.csv
yup this looks as would be expected
there shouldn’t actually be any file called “ connec ”
so … this bit requires a bit of explaining… Yes there is a single output that is called “connec1-1.tck”. This is by design (and hence the “-keep self” flag). We are trying to extract at the “whole network” from our differing ROIs so we did not split the ROIs into separate ROIs.
The output of that would be fed into the FBA pipeline to generate fixels for our network of interest.
This issue is that the connec1-1.tck file is blank when @yanadim2 tries to generate it on her machine but works as expected on mine! I suspect that this has something to do with her mrtrix install. I tried to see the -debug output but nothing odd popped out …
This issue is that the connec1-1.tck file is blank when @yanadim2 tries to generate it on her machine but works as expected on mine!
When you say it “works as expected” on your system, there should be a lot of track files that begin with “connec”; one for every edge in the connectome. Is that the case?
connectome2tck writes track files differently to other MRtrix3 commands. Normally, track data are written to a buffer in RAM, and the contents of that buffer are appended to the existing track file whenever the buffer becomes full. In connectome2tck however, each output track file is opened and appended for every individual streamline written to it. While I don’t see any reason why this would fail on any particular system, especially if other MRtrix3 commands that write track files work as expected on that system, there’s a good chance that it’s an important detail in one way or another. When running on the problematic file system, does the output destination happen to be a network file system?
When you say it “works as expected” on your system, there should be a lot of track files that begin with “ connec ”; one for every edge in the connectome. Is that the case?
No, there is only one file with “connec.” This is because there is only one node in the network and we have kept self connections. Hence we can only have connec1-1.
When running on the problematic file system, does the output destination happen to be a network file system?
No, the command was being run on a macbook, I am not sure of the precise version. The command worked well on my system running ubuntu. It’s a very peculiar error and the -debug option did not output any particularly useful information.
This is because there is only one node in the network and we have kept self connections.
Ah OK, such a non-standard usage definitely has the potential to expose some slightly flawed internal logic somewhere. Still unusual that the issue would arise on one system but not another, but it at least gives much clearer instruction as to how we might go about reproducing and hence debugging. Keep track of proceedings over on GitHub.
A couple of things worth testing though:
Can a standard connectome from a parcellation with more than one node be produced OK on that system?