What is the difference between these two methods for generating tracts between a seed image and target ROI? If I run both, I end up getting a similar number of streamlines (but not exactly the same) when I keep the rest of the parameters constant.
The numerical differences between the two are likely principally stochastic, and if you were to run both experiments multiple times, the average number of streamlines between the two approaches would come out to about the same. This is specifically because you’re using “-seeds 10000 -select 0”, which means that 10,000 streamline seeds are propagated from, regardless of how many are successful; under default tckgen usage, where the number of output streamlines is fixed, the latter usage would always lead to an equal or lesser number of streamlines than the former.
The more esoteric answer is that in the former case, all three vertices of each half-voxel iFOD2 “step” are compared to any provided ROIs, whereas in the latter case, the streamlines data have already been “downsampled”, such that the vertices in the track file are half a voxel distance apart, prior to comparison to image target_mask.mif. So there may be some rare instances where the latter usage would reject a streamline that would have been retained by the former usage, if it’s only one of those “in-between” vertices that resides within a voxel present in the mask.
I am getting varied results in output1.tck and output2.tck. However, when I tried what is explained above, its similar results on average.
I am trying to make sense why this is happening. Could you please refer to a paper where I can get a better idea.
The difference between @sabco’s usage and yours is the use of -seeds <nonzero> -select 0 vs. -select <nonzero>, and the consequences for what the command does as a result. This isn’t described in a manuscript, it’s just the MRtrix3tckgen interface. In your usage (which is more common), tckgen will continue seeding and propagating streamlines until it has written 100,000 streamlines to the output file. Each of those 100,000 streamlines satisfy all criteria imposed on reconstructed streamlines in order to be deemed “acceptable”.
In your method 1, 100,000 streamlines are generated, regardless of whether or not they intersect targetimage.nii.gz. tckedit will then select from those 100,000 streamlines only those that traverse targetimage.nii.gz. Let’s say for the sake of the argument that about 1% of streamlines seeded in seedimage.nii.gz intersect targetimage.nii.gz; so filteredtracks.tck will contain about 1,000 streamlines.
In your method 2, tckgen will continue until it has generated 100,000 streamlines that intersect targetimage.nii.gz. If 1% of generated streamlines succeed in doing so, that means tckgen will need to generate about 10,000,000 streamlines before it produces those 100,000 “acceptable” streamlines that satisfy the criterion of intersecting targetimage.nii.gz. As a result, output2.tck has about 100 times as many streamlines in it than does filteredtracks.tck.
Thank you for your reply. It is really helpful to understand.
Just one more query, if we assume there is some anatomical ground truth (meaning in any adult healthy brain, seedimage to target image is 5000 streamlines anatomically, just as an example), what do you say is better or most accurate way of finding something close to this ground truth. What is a better approach; the one @sabco suggested at the start of the discussion or option1 in our approach.
if we assume there is some anatomical ground truth (meaning in any adult healthy brain, seedimage to target image is 5000 streamlines anatomically, just as an example)
Anatomy does not contain streamlines. Streamlines are merely digital reconstructions of estimated white matter pathways. The number of streamlines to generate is that necessary to “adequately” reconstruct the possible spatial trajectories of white matter bundles given the constraints imposed, which is not necessarily proportional to the density of white matter fibres contained within such (which is the domain of methods such as SIFT / SIFT2.