Error in header when using a function [read_mrtrix_tracks]

a .tck file specified ending points was generated by following code:
connectome2tck $ROItck_file $assign_file tck_native_ROI -node ${i},${j} -exclusive -keep_self -force -nthreads 10
here, I set node {i} and node {j} same.
then I use function read_mrtrix_tracks in matlab to read this .tck file. It doesn’t show an error, but a message “invalid line in header: ‘count444408’ - ignored” appeared. I don’t know whether this message means somehting wrong in my .tck file, and did this wrong influence my further analysis.

Welcome Jane!

This is quite a strange one. That looks like a genuine corruption of the file header. Now it is true that the code will simply ignore that field and continue, and that the “count” field in the header is not technically requisite.

However I would be skeptical of the notion that this is the one and only location in which the file was corrupted; corruption of the streamlines data itself would almost never be identified automatically by the software.

Are you able to reproduce the same fault by re-running the command? That’s always the first test for odd-looking corruptions like this; we can’t remotely diagnose unexpected bit-flips due to rogue solar neutrinos…

Cheers
Rob

I agree with you that streamlines itself are not corrupted. I do re-run this command for the ‘count’ errored node separately, then the ‘count’ message will disappear. And I also compare the value of ‘count’ errored data and re-running data using function read_mrtrix_tracks, there is nothing different in terms of value. But if I run:
connectome2tck $ROItck_file $assign_file tck_native_ROI -node ${i},${j} -exclusive -keep_self -force -nthreads 10
for all nodes in a for loop. The ‘count’ problem will appear again. I cannot rerun all nodes with ‘count’ message, because I have many nodes and many subjects. So I just ignore this problem. :woman_facepalming:

  1. So to be clear: If you execute connectome2tck once, for one specific pair of nodes, the .tck file is malformed; but if you use a bash for loop and execute connectome2tck many times, the .tck header is malformed? Is it all of the results of connectome2tck when run in such a loop, or just one specific & repeatable instance, or does it occur at random? I don’t see any mechanism by which this difference in execution could have such an effect on file corruption, so I want to make sure that I understand the claim correctly, and that it’s not a mis-interpretation of something that’s occurring randomly or due to some correlated process.

  2. I think there may be an under-appreciation of the capabilities of connectome2tck here. You should only need to run the command once, with the input to the -node command-line option being a comma-separated list of all nodes of interest; the command will by default generate one track file for every edge for which both nodes connected via that edge appear in the list. Running it once per pair of nodes is an unnecessarily inefficient way of reaching that outcome.
    Alternatively, if you are truly looping over “all” nodes, then you should omit the -node and -exclusive options entirely: the default behaviour of the command is to produce one track file per edge, and it looks like that’s what you’re trying to achieve.

According to your suggestion, I check which operation will make errors. First, node here, I didn’t use a brain region with small size, I use a network, like visual network. So I think it is necessary to obtain the tracts within this network. therefore, you can see I use -keep_self option.

  1. I must say this errored .tck file all appear in the within-network pair, such as within visual network. Nothing wrong in between-networks pair. Then, I execute connectome2tck once, for one specific pair of networks, the .tck file is ok. but if I use a bash loop for all subjects all networks-pair, the .tck header is malformed. It didn’t occur randomly, it is just appeared in several specific subjects with specific within-network pairs, like subject 01 within visual network or subject50 within default network.
  2. Because there are further operation for the acquired .tck file which I must preknow the specific index of between-networks pair, I cannot just input to the -node command-line option being a comma-separated list of all nodes of interest. In this way, I just know which node I interested, but I don’t know which nodes are connected to this node. Actually, I have extracted the valid network pairs from the output .csv file ($csv_file) from
    tck2connectome $ROItck_name $atlas_dwi $csv_file -out_assignments $assign_name -force -nthreads 10
    to avoid empty tracts and speed up computing.

I didn’t use a brain region with small size, I use a network, like visual network. So I think it is necessary to obtain the tracts within this network. therefore, you can see I use -keep_self option.

Okay, so you have multiple disconnected parcels, all of which have the same index. While that can be done, it can also lead to unintuitive behaviour. For instance, the output with -keep_self won’t only contain streamlines that connect all disparate parcels, it will also include streamlines that self-connect to the same parcel. I personally consider it more appropriate in these circumstances to allocate the spatially disconnected parcels uniquely; the fact that a certain set of parcels constitute some network of interest is a higher-order interpretation of such. Doing it this way would also enable you to use connectome2tck to obtain separate track files for each unique edge within that network of interest, whereas currently you can only ask for “those streamlines for which both endpoints are allocated to the network”.

  1. I’ve not been able to reproduce this fault locally, so I’m limited in what I can suggest. If it’s a problematic issue, and you’re unable to isolate precisely the circumstances in which it arises, you could make available to me data for one example where it arises, and I can try running that myself to see if the same thing happens at my end.

Rob