Hi,
I just noticed that my exclusion ROIs with tckedit don’t seem to be working, see attached figure.
I’m using 3.0_RC3_latest-66-g323bc8ac.
The blue ROI is the exclusion ROI, therefore the streamlines running through that blue ROI should be rejected from my pov (edit: red ROIs = inclusion ROIs).
Best, Lucius
That’s worrying… Can you check what the thickness of those ROIs was in millimeters? And also what step size was used during the tractography? There’s a chance that if the step size is larger than your mask’s voxel size, the algorithm might ‘step over’ your ROI with no vertices actually falling within the ROI…
Ok, great thank you for the solution. I enlarged the ROI and it rejected the streamlines.
Unfortunately it’s not my data, so I don’t know about tckgen’s step size…
Voxel size was .7mm
tckinfo should report that. But that’s is quite a small voxel size.
Moving forward, not sure how to deal with that in a way that prevents these kinds of issues. I think the simplest might be to issue a warning if we detect that the step size is larger than the voxel size. Anything else is likely to have a performance penalty…
I must have been confused. Voxel size of the tractogram was 1.0,1.0,1.0).
Yes, a warning would be very nice!
I assume you mean the step size was 1.0 mm…?
In any case, I’ll make a note add these checks and issue warnings to avoid the worst effects of this. It still won’t be perfect since streamlines might go through ROI corners, etc. without being rejected. But I’m not sure how we can implement a more robust strategy without some significant performance penalty…
This is what I get:
luciusfekonja@LuciusFekonjasMBP s5 % tckinfo tracking-probabilistic.tck
***********************************
Tracks file: "tracking-probabilistic.tck"
count: 0001822957
dimensions: (181, 218, 181)
voxel_order: LAS
voxel_sizes: (1.0, 1.0, 1.0)
luciusfekonja@LuciusFonjasMBP s5 %
It still won’t be perfect since streamlines might go through ROI corners, etc. without being rejected
Yes I noted that, with a very few streamlines. I guess in this case here maybe tractography has not been performed via mrtrix, therefore there is no step size info?
In any case, I’ll make a note add these checks and issue warnings to avoid the worst effects of this.
Thanks!
Yes, that’s definitely not one of ours… We unfortunately don’t have a simple way of dumping out the step size – even though it is often required in various apps. Maybe @rsmith will have some trick here. But given that increasing the thickness of the ROI does the trick, I don’t think we need to dig any further…
I suspect you are working with “compressed” streamline files (e.g., removing co-linear points to reduce file size, etc.). In that case, imagine having 4 points in a straight line, separated by a 1mm step size. This would result in a line segment being compressed into 2 points (start and end), separated by a 4mm step size.
Using conventional ROIs will often fail with compressed tracts files, I recall this was showcased by JC Houde at ISMRM some years ago, and also by Francois Rheault in this paper:
Best,
Max
That was the problem, as just mentioned by mail to me for confirmation:
(the step size was originally 1/10 the size of the voxel, but once compressed they are represented by much less points and can actually “step over” an exclusion region).
Best, L
Some ongoing discussion in GitHub #1855.
The method described in Appendix 3 of the SIFT manuscript provides a more robust mapping of streamlines to voxels; that mechanism is however not yet available in tckedit / tckgen.
Good to know, thank you very much for the hint!
Hi all,
I have a related issue. I have a bunch of whole-brain tractograms of post-stroke patients, created with the iFOD2 algorithm and followed by sift2. I then filtered the tractograms using tckedit with the hippocampus (from FreeSurfer’s hippocampalsubfields) as -include region and the lesion (manually delineated) as -exclude region. As the voxel size of the hippocampus (0.33 mm isotropic) and lesion (0.67 mm isotropic) segmentation are smaller than the algorithm’s step size (1.08 mm), I get the warning discussed above. I tried several things to check whether my results make sense (number of streamlines for an example subject between brackets):
I get the same warning using approach 1, 3 and 4. All approaches (except for 0 and 4) require long computation times and/or have large file sizes so are therefore not feasible to run for the whole group (only exploratory). How can I make sure that my results are correct? Visually, there is almost no difference between 0, 1, 3 and 4. Only with a smaller step size, the results look visually different.
Thank you for your help!
All the best,
Klara
I’m not sure we have a good answer to this currently. This remains an open issue, and it’s difficult to solve properly without significant performance penalty. It’s important to note that this issue will affect all tractography, whether or not the step size is smaller than the mask’s voxel size: streamlines that intersect the corner of an ROI can still be missed if the sample points happen to fall outside the corner. It’s just that the proportion of such streamlines will be tiny when the step size is smaller than the voxel size, and get progressively larger as the step size increases relative to the voxel size. It’s also considerably worse if the ROI is thin: a streamline can easily ‘jump’ right through a slice-wise ROI if the step size is larger than the thickness (voxel size) of that ROI (that can’t happen if the step size is smaller though, thankfully).
To solve this requires a more precise means of checking for genuine intersections, but that either requires (much) denser sampling, or a different (and more computationally onerous) means of checking for intersections (the ‘precise’ mapping approach mentioned in this issue). This can’t be done without significant and deep changes to the code, which is no trivial undertaking…
As to where that leaves you, I would say that your option 1 would probably be the simplest, but I can see that the requirement to store a very large intermediate tractogram is problematic (incidentally, this probably wouldn’t be such an issue if we could implement streamline piping, which would avoid the need to store the temporary streamlines). If that’s not an option, I think your best bet is probably option 4 (though you’d probably need to resample to a slightly larger voxel size to avoid the warning), as long as the resulting ROIs remain faithful to their original full-resolution versions.
Hi,
Thanks a lot for your quick reply and recommendations, I really appreciate it!
Have a nice day,
Best wishes,
Klara