Hi MRTrix community
I have a problem with the tckgen command for alogirthm different from iFOD. Here is the code:
Dabei ist alles in Python geschrieben und hier sind die Parameter:
The issue here is that the main input file that needs to be provided to tckgen can change depending on the particular tracking algorithm being invoked; this is listed in the command’s help page.
So when you provide file %s_fod.mif to tckgen -algorithm fact, which is an image containing spherical harmonics, most likely of maximal harmonic order 8 (45 volumes), the FACT algorithm is mis-interpreting these data as 15 triplets of XYZ fibre directions in each voxel. This will inevitably lead to erroneous tracking (I’m guessing the images have been mis-labeled: the upper erroneous image is FACT, whereas the lower one is SD_Stream). tckgen is unable to detect the fact that you’ve provided the incorrect image since it actually satisfies the requirements for that algorithm (number of input volumes must be a multiple of 3).
To get tckgen -algorithm fact working, you can use either sh2peaks, or fod2fixel combined with fixel2voxel split_dir.
it worked quite good alike the iFOD algorithm. But why does SD_Stream look different and I also testet Nulldist and there one gets this noise image:
Nulldist2:
OK, thanks for reporting those results; it opens up an interesting discussion.
For the sd_stream algorithm, the default step size is 1/10th the voxel size, and the angle of curvature constraint is applied at every step. Since the steps are so small, the default angle of curvature is correspondingly small: just 9 degrees per step (equivalent to 90 degrees per voxel, which is the same as that used in the default iFOD2 algorithm). By increasing the permitted angle to ~ 90 degrees per step, essentially no curvature constraint is applied at all, with the tracking algorithm instead relying entirely on FOD amplitude / mask constraints.
However with the default curvature constraint, in my quick experiment, over half of the streamlines generated are terminated due to the curvature constraint; and as you observed, there are ‘strips’ of white matter where there are no streamlines. This I suspect is due to the tracking algorithm performing interpolation directly on the FODs in their native spherical harmonic basis: If the angle between FOD peaks in successive voxels is relatively small, then the peak orientation will ‘rotate’ relatively smoothly as this SH interpolation is performed between the two voxels; however if the angle is larger, then the peak orientation will not rotate smoothly; interpolation will instead result in one peak diminishing until it disappears, and the other growing until the peak appears, as the position moves from one voxel centre to the other. Consequently, as a streamline tracks between those two voxels, it will experience a sudden change in orientation in one particular step, rather than a smooth transition in orientation across all steps, and this is more likely to exceed the curvature threshold.
One thing that can help in this situation is to up-sample the DWI volumes prior to spherical deconvolution, and then manually set the step size and angle parameters to what they would have been for the native resolution data. Interpolating the DWI data tends to produce smoother transitions in FOD peak orientation than interpolating the FODs themselves.
@jdtournier Any thoughts on adjusting the default curvature threshold for this algorithm?
Yes, @rsmith is spot on. This particular issue is discussed in detail in this paper (see figure 2), and is one of the reasons I don’t recommend its use in practice. The simplest ‘fix’ is to open up the angle of curvature to allow sharp turns, as you’ve already figured out. But that does allow unnatural ‘kinks’ in the trajectories, and increases the potential for artefacts such as streamlines making U-turns, etc. So it’s a delicate balancing act between allowing streamlines to progress along what must be the most likely direction of travel, and introducing too many spurious streamlines.
This issue isn’t going to be specific to this implementation by the way, any multi-fibre deterministic algorithm will have to deal with situations where the orientation being followed is no longer present at the next step (as illustrated in the paper above, or simply because the SNR is no longer sufficient to recover that fibre population, etc). The algorithm will then have to decide whether to terminate, or follow the next closest orientation. The question is then: how close is plausible? This is what the -angle option allows you to specify - but it is inherently a compromise.
What is undeniable though is that the default angle is not appropriate for this algorithm. In fact, in MRtrix 0.2, the default is to disable the angle constraint altogether (-curvature defaults to 0). I guess I’ve neglected to set this appropriately since I essentially never use that algorithm… I think the better default would be a hard value (i.e. not dependent on step size or voxel size, as per the current default), maybe between the 45° and 70° mark - any wider would allow complete changes in direction, which we should assume are implausible. @Ingo: how did you come up with the 77° value by the way? It seems very specific, was there a dramatic difference at that point…?
The nulldist / nulldist2 algorithms are supposed to be noisy; that’s their defining attribute (“Null Distribution”). I would suggest reading the relevant article that is cited in the tckgen command’s reference section.
This thread and the answers from @rsmith and @jdtournier have been very helpful in coming up to speed with different algorithms! So I’m getting the idea that the SD_Stream algorithm is essentially deprecated in favor of ifod1 and ifod2?
FWIW
I was getting ready to post a long question as to why SD_Stream produced tracts limited in space:
Well, deprecated may be too strong a word here. But I personally don’t recommend it… Irrespective of the oddities of deterministic tracking on FODs, I think there’s just far too much uncertainty in the whole process (far beyond just imaging noise) to justify relying on a deterministic approach. The default is currently iFOD2, and that would be my recommendation for tractography in general. Of course, there may be cases where other approaches perform better (not sure they’d necessarily be more appropriate though), and bear in mind that others may also have different opinions on the matter (I know many other researchers in tractography are far more pro-deterministic than I am…).
And then there is also a whole spectrum of “more (or less) probabilistic/deterministic” of course. Using the -power option, one can “make” e.g. iFOD2 also behave more (or less) deterministic, all the way up to letting it behave very close to deterministic…
I’m not sure what you mean here. There’s an option to hide the main image in the view menu, which you can use in combination with the tractography tool’s ‘crop to slab’ option. Another possibility is the MRView ‘volume render’ mode, also in the view menu. This works best with clip planes, which you can add via the ‘view options’ tool. Otherwise, you’ll have to be a bit more specific as to what you’re after…
Hi @jdtournier,
Sorry, I didn’t fully clear.
I’ve got to the answer from your answer. Thank you! I can use the tractography tool’s ‘crop to slab’ option to display my results.
However, can we rotate with different angle to watch the 3d images in MRView?
I got the FACT to work by converting fod2fixel and then fixel2peaks. This produced an image that was a multiple of 3, and was used as input for tckgen with the FACT algorithm.