Tckmap issues

1

Hi,

I successfully converted trk file to tck but when I run tckmap it just creates a volume of zeros.
(py3k) clint@crash:~/Desktop/warped_trks$ tckmap -template 100307_fa0.nii.gz new_test.tck TDI.nii.gz -force
tckmap: [WARNING] existing output files will be overwritten
tckmap: [100%] mapping tracks to image
tckmap: [100%] compressing image “TDI.nii.gz”

Here http://mrtrix.readthedocs.io/en/latest/getting_started/image_data.html?highlight=format#tracks-file-format-tck it lists file offset and datatype key value pair as being necessary. I have also included count and step size key value pairs in my header because it was complaining about it.

Is there some other key value pair that could be missing? For reference here’s the header
In [13]: tck.header
Out[13]:
{’_dtype’: dtype(‘float32’),
’_offset_data’: 67,
‘count’: ‘0000005000’,
‘datatype’: ‘Float32LE’,
‘endianness’: ‘<’,
‘file’: ‘. 67’,
‘magic_number’: b’mrtrix tracks’,
‘nb_streamlines’: 5000,
‘step_size’: 0.5,
‘voxel_to_rasmm’: array([[ 1., 0., 0., 0.],
[ 0., 1., 0., 0.],
[ 0., 0., 1., 0.],
[ 0., 0., 0., 1.]])}

Thanks any help appreciated

2

Can you display these tracks in mrview? Maybe the conversion failed? If not, one other explanation might be that your 100307_fa0.nii.gz template image does not overlap with the streamlines - they all map outside that volume?

Can I ask how you did this? If this was done by editing the header directly, you need to be very careful about the byte offset in the file: entry - it will most likely have changed.

You could also verify that the tck file is readable by running:

$ tckinfo -count new_test.tck

and make sure that it reports the expected count (without the -count option, the count reported is just the contents of the corresponding header entry, there’s no guarantee that this information matches what’s actually stored in the file).

I would expect tckmap to abort with an error if there was any critical information missing. The fact that it ran suggest the problem is either with the conversion itself (i.e. the streamlines data themselves are wrong), or with the template being in the wrong place (as suggested above).

3

I cannot display them in mrview. I used this script that uses nibabel: https://gist.github.com/MarcCote/ea6842cc4c3950f7596fc3c8a0be0154.

Here’s the output when I run tckinfo test_5thous.tck

Tracks file: "test_5thous.tck"
count: 0000005000

4

‘file’: ‘. 67’,

This is almost certainly incorrect. The meaning of the value (the text entry on the right hand side of that line) indicates that the data are stored in the same file as the header information (“.”), at offset 67 bytes. However there are more than 67 characters in the header printout you have provided, which means the track data can’t possibly start that early in the file. So if the .tck file being created is malformed, there’s not really anything we can do about it from our side, except for advise on what the file should in fact look like.

At least until we have track file format handlers, which seems to be becoming increasingly pertinent…

Rob

5

The file offset is not the issue. The header is only 67 bytes. In addition, I upgraded to the latest version of mrtrix on github. Tckmap no longer complains about a lack of step size in the header. I get a workable TDI image if I run tckmap new_test.tck TDI.nii.gz -vox 1.25 so it’s reading the tck streamline data fine.

However, if I run tckmap -template 100307_fa0.nii.gz new_test.tck TDI.nii.gz I just get a volume of 0’s and I need it aligned to the template so the -vox 1.25 isn’t going to work.

Thoughts?

6

The fact that you get a meaningful TDI using tckmap -vox, but not with tckmap -template, means that it must be a spatial localisation problem.

When you use the -vox option in the absence of the -template option, the tckmap command examines the spatial extent of the streamlines data, and uses that to determine the spatial location of the output image FoV. Conversely, if the -template option is used (regardless of whether or not -vox is also used), the spatial location of the output image is defined by the template image. So basically, your streamlines do not overlap with your template image. One way to test this is to load your template image in mrview, load the streamlines in the tractography tool, turn off “crop to slab” in the tractography tool, and keep zooming out until you see the streamlines.

A likely source of the discrepancy is the coordinate convention used. MRtrix3 expects streamline vertex locations to be defined in scanner space. So if the software producing the .tck file is not internal to MRtrix3, there’s a chance that it is not conforming to this, instead writing the vertex locations according to some other convention, which has the effect of translating / rotating / scaling the tractogram in 3D space, such that it no longer overlaps with your template image. If this is indeed the case, one of the tckconvert transformation options may solve the issue.