Exclusion rois not working properly

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

1 Like

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…

3 Likes

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

1 Like

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!