This question is related to this previous post, although not entirely.
I would like to obtain a tract with fixed ends between two ROIs.
One way would probably be to use tckgen and specify one ROI as the seeding ROI, the other as an inclusion ROI and have the streamlines stop when having reached both ROIs:
However, in that case it would matter which ROI I use as seed, and which as the include region. Therefore my plan instead was to start from a whole brain filtered tractography:
However, tckedit has no option to crop/stop/end a tract between the inclusion regions. Can someone recommend a workaround, or should I use tckgen instead (ignoring the bias of the choice of the seed ROI)?
A way to work with this, but avoid the potential bias as to which region is seeded from, would effectively be to do this both ways, and combine the results. Although in your example, this would still not get you what you were looking for: even seeding from a region doesn’t guarantee it to only track in one direction; for that you’d need the unidirectional option and probably also indicate a starting direction. But even then, streamlines would still be present in your seeding regions, while being not present in your inclusion/stopping region, as they stop upon hitting the latter one. So it’s again not exactly “between” 2 ROIs… depending on how you read/interpret the word “between” there…
A workaround of sorts at the tckedit stage may be to use the -mask option, and essentially mask out the bits that are beyond the regions… but depending on how messy and extensive they are, this may still be a very manual approach. Of course, if the actual bundle itself is relatively limited in size, you could draw a mask that simply includes the bundle, but doesn’t include the bits you want to get rid of. You could even potentially go with a track count map (tckmap) and use a clever threshold to get an initial mask, and then edit that a bit further to your liking to get an appropriate mask for tckedit. This may work decently if your bundle itself is quite compact, but the streamlines start dispersing a lot the moment they’ve hit your “end” regions, due to no further constraints applying beyond that point. The track count would inherently drop quite a bit at those points. Actually, now thinking of that, you could go with the example that I gave in the post you linked to, where I used the -stop option to tckgen in an “unsuccessful” way, but I did end up with a strong track count drop beyond my intended “endpoint” regions…
@jdtournier, @rsmith: any other bright ideas how to succeed at the use case @tbilliet described? It’s actually one that I hear quite often from users… if it can’t be done in a straight forward manner with the current functionality, this may be a candidate for improvement of either tckgen and/or tckedit…
tckedit -mask is really the only way to get something like this done currently. This topic introduces issues not entirely dissimilar to the recent discussion around tcknormalise dealing with streamlines exiting the image region containing valid non-linear warp data: As soon as only part of a streamline may be considered “valid”, it’s possible for an individual input streamline to be split into multiple output streamlines.
tckedit -mask actually permits this currently. So, as an example, you could take the summation of your two ROIs, invert that image, and then use this as a mask, removing all vertices inside the two ROIs. However this would provide you with not only a cropped bundle between your two ROIs, but also any extraneous track segments where the streamlines continue beyond either ROI. Currently the only way to remove these would be to manually draw a mask and remove them with tckedit, which would therefore not really save any effort over and above manually drawing a mask to capture only those streamline vertices between the two ROIs to begin with.
The only way that comes to mind to achieve this in a properly automated fashion, that hopefully makes sense in all use cases (e.g. more than two include regions), and doesn’t require a tremendous amount of work, would be to implement a -longest option that could be used in conjunction with -mask to select, for each input streamline, only the longest set of connected vertices. This would however only work if the pathway of interest is longer than the “extra” bits of track beyond the two ROIs, and hence survives the “largest connected component filter”. For anything more advanced, I can probably always come up with an alternative use case where the correct / expected behaviour is ambiguous.
