I think that what you’re looking for is something like this script. You could either run it in a loop, where on each iteration you generate a binary image corresponding to just one of the parcels and use that as the seed image, or you could produce a modified version of that script that simply uses every voxel present in the input parcellation as a seed voxel.
However, I suppose I am unsure how to get streamlines that originate in a given voxel (
fixed_seed_tracks.tck ), given that the parcellations include cortical gray matter.
Well, yes; for this sort of fine-detailed approach, using surface vertices for the cortex rather than voxels would be preferable. The aforementioned script at least exploits a trick whereby if it looks increasingly unlikely that the requested number of streamlines can be generated from a given seed, it will abort execution for that particular voxel. Using GMWMI-based seeding for such parcels would also potentially be preferable; but again, if you wanted to do this for cortical parcels but not for sub-cortical parcels, you’d need to modify the code.
Technically you could also take the cortical GM partial volume image, add it to the sub-cortical volume, and zero out the cortical GM volume, which would permit streamlines to be seeded in, and track into, the cortex. Though I don’t personally expect the resulting trajectories to be trustworthy in the absence of information over and above the low-spatial-resolution FODs.
I am of course assuming that you are using ACT based on your description, though you didn’t state so explicitly. (Edit; it’s in the second post)
That is, using the full premade tractogram would both render it hard to associate streamlines with origin voxels and leave no way to ensure that each voxel was seeded the same number of times.
Yes and no for both:
You can get
tckgen to output the seed location for each streamline; see
-output_seeds. It’s a bit of a hack though, and you’d need your own code to utilise such.
Generally for this sort of “endpoint-seeded tracking”, you would be performing unidirectional tracking, in which case the seed point is the first vertex of the streamline. The
-vector option in
tck2connectome, which is used in the
maskconnectivity script linked above, exploits this knowledge to only consider the last vertex of each streamline when assigning to parcels.
There is a difference between “ensuring that each voxel was seeded the same number of times”, and “ensuring that the same number of streamlines generated from each voxel were written”. Both the proportion of streamline seeds resulting in streamline propagation, and the number of generated streamlines satisfying all criteria and being written to file, can differ between voxels.
-seed_*_per_voxel only guarantees an equal number of seeds per voxel. So while you could use one of these options and provide all non-zero voxels within the parcellation as the seed image in order to do whole-brain tractography, the guarantee provided by such may not be precisely what you’re looking for.
maskconnectivity on the other hand, because it explicitly runs
tckgen multiple times with a single voxel seed each time, guarantees an equal number of exported streamlines per seed voxel.
If I do this, will there be a way to associate streamlines to the voxel they were seeded from? Is that what the
-output_seeds argument would specify?
-output_seeds will give, for each streamline, the vertex index that corresponds to the seed, as well as the real-space position of the seed vertex. This would need to be transformed to determine the voxel in which that seed resides. But as previously, it’s unclear how to interpret such. If you are interested in how one voxel connects to everything else, but the streamlines seeded there are propagated in both directions, does that streamline contribute two connections to that voxel or just one?
Perhaps I’ve misunderstood how
-seed_random_per_voxel, because the number of streamlines I was getting seemed to far exceed the number of voxels in the mask*5000.
Assuming you requested 5000 seeds per voxel, the total number of streamlines should never exceed that product. If this is definitely the case and not a misunderstanding, that would need to be looked into.