When applying tck2connectome to track files containing streamlines which exit the volume through the brainstem for example, are the tracks counted as terminating in the brainstem, or are they ignored?
I’d just like to be sure that such streamlines are not counted because this would lead to artifactually elevated connectivity for the brainstem, which is problematic for my use case.
Thanks,
Marmaduke
It depends on, for instance, the parcellation you’re using and where the streamlines terminate relative to those parcellations:
If you have a brainstem parcellation that extends all the way to the inferior edge of your anatomical image, and your DWI has less spatial coverage in the inferior direction than your anatomical image (typically the case), then there’s a good chance that those streamlines terminations caused by exiting the DWI FoV (which occurs before exiting the anatomical FoV) will reside within the brainstem parcellation.
If the brainstem parcellation is ‘cropped’ such that its inferior edge is at least 2mm above the inferior edge of the DWI where the streamlines terminate, then those streamlines shouldn’t be added to that parcellation.
These types of questions are also dependent on the mechanism that’s used to assign streamlines to parcellations (accessible using the -assignment_* options in `tck2connectome). The default mechanism simply searches within a 2mm radius around the streamline termination in search of a labelled voxel; so this is blind to the fact that a particular streamline may have been terminated due to exiting the image FoV rather than encountering grey matter.
In the absence of a more robust automated streamline-to-parcel assignment mechanism (which I may look at adding in the future), you have a couple of options:
Remove those unwanted streamlines using tckedit with a manually-drawn mask prior to running tck2connectome.
Use the -spine option in labelconvert to manually add a ‘spinal column’ ROI to your parcellation image, that (if drawn correctly) will ‘claim’ those streamlines exiting the FoV, rather than the brainstem parcel.
Cheers
Rob
Thanks for the detailed reply. Option 2 to explicitly capture ‘spinal column’ streamlines is a really neat idea. Thanks for the suggestion!
Hi @rsmith, we are trying to achieve to add the spine node via the -spine option in labelconvert. However, unfortunately we weren’t lucky yet and not able to add a manually drawn spine ROI to our DKT atlas derived from fastsurfer. Could you please specify how to draw the spine ROI correctly and add it to the converted node image? We checked the sifted tractogram and edited it with -include spine_roi.mif to confirm that there are indeed streamlines connecting to the drawn spine ROI.
Cheers, Lucius
Hey Lucius,
I can’t infer from your description exactly what may have gone wrong there. But one hypothesis looking at the code is that if your target lookup table does not actually include an entry “Spinal_column”, then use of the -spine command-line option will not actually produce any error or warning. What will happen instead currently is that any voxels included within the binary mask image that you provide will be set to value 0 (i.e. no parcel) in the output image. So this is the kind of “silent failure” that might lead to your current confusion.
If there is not an entry “Spinal_column” in the output LUT, it’s not possible for the labelconvert command to add that mask to the parcellation image, as it has no way of knowing what value should be assigned to those voxels. While one could argue that it could simply determine the smallest unused parcel value, this would result in a parcellation image where there is no longer proper correspondence between the values in the image and the values in the lookup table. So I think that having the command produce an error in this instance would be the more sensible outcome.
The only other possible source of confusion I can think of right now is where the voxels are added for this region. Because the parcellation image is intended to be used with tck2connectome, it implicitly needs to be compatible with the mechanism for assigning streamlines to parcels that is used within that command. So the voxels within that binary mask need to be drawn where the streamlines terminate, as opposed to a ROI more superior where the streamlines may pass through, and may be selected e.g. if used with tckgen -include, but would not be identified based on the default radial search mechanism in tck2connectome.
Cheers
Rob
Thank you very much, after inspecting labelconvert.cpp it finally became clear that “Spinal_column” is the exact name it was looking for.