Hi Céline,
-
Yes, that argument is not actually an “output”; I should think of a different name for it. It’s the lookup table to which you want your output image to conform.
Generally if you’ve taken a lookup table that MRtrix3 can already read, and simply modified the indices, then there shouldn’t be a problem. However it only takes one slightly erroneous line for the code to detect an inconsistency in the formatting and hence be unable to read the file: It’s looking for a consistent number of columns in each row. While the list of supported formats isn’t in the documentation, you can see the possibilities in the code here. I do have code somewhere for making errors in parsing here more verbose in response to this thread, but I can’t recall where it went; if you get stuck, you can try posting the contents of the file here.
-
It took me a moment, but I think I know what’s going wrong here. The connectome tool determines the centre of mass of each node in 3D, and draws the node (by default a sphere) at that location. For all of the nodes to be aligned on a sagittal plane would require that the centre of mass of every single node lies on a sagittal plane. There are only two ways in which this could occur:
-
(unlikely) Every node only contains voxels on a single sagittal plane.
-
(likely) Every node is labelled identically in both hemispheres, resulting in a centre of mass that lies on the mid-sagittal plane.
The latter I believe I’ve observed in FSL atlases, and was the reason why I haven’t provided lookup tables for those atlases within MRtrix3: That labelling can’t be resolved for use with
tck2connectomeusinglabelconvert, explicit image manipulation is instead required. I imagine that you would need to find / derive a hemisphere mask image, and add some integer number to node values within that masked hemipshere, in order to get a unique integer for each node (including homologous regions between hemispheres). -
Rob