# Just iFOD1 and iFOD2 works, FACT not **URL:** \ **Category:** Uncategorized\ **Tags:** tractography\ **Created:** [February 15, 2017, 11:55am UTC](https://community.mrtrix.org/t/just-ifod1-and-ifod2-works-fact-not/722 "2017-02-15T11:55:04Z")\ **Posts on this page:** 19\ **Page:** 1
**Author:** ![Ingo](https://community.mrtrix.org/letter_avatar_proxy/v4/letter/i/e19adc/32.png) [@Ingo](https://community.mrtrix.org/u/Ingo)\ **Post date:** [February 15, 2017, 11:55am UTC](https://community.mrtrix.org/t/just-ifod1-and-ifod2-works-fact-not/722/1 "2017-02-15T11:55:05Z")
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: > opt\_1 = ‘-number 200k -act 5TT.mif’ > algorithm = “FACT” > os.system('‘5ttgen fsl /home/ubuntu/E130-Daten/IngoHermann/%r/T1w/T1w\_acpc\_dc\_restore\_brain.nii.gz 5TT.mif -premasked’ % input\_number) > os.system(‘mrconvert data.nii.gz %s.mif -fslgrad bvecs bvals -datatype float32 -stride 0,0,0,1’ % name\_DWI) > os.system(‘dwibiascorrect -fsl %s.mif -’ % (name\_DWI)) > ``` > os.system('dwi2mask %s.mif %s_mask.mif' % (name_DWI, name_DWI)) > > ``` > ``` > os.system('dwi2response tournier %s.mif %s_response.txt' % (name_DWI, name_DWI)) > > ``` > ``` > os.system('dwiextract %s.mif %s_ex.mif -bzero' % (name_DWI, name_DWI)) > > ``` > ``` > os.system('dwiextract %s_ex.mif - -bzero | mrmath - mean meanb0.mif -axis 3' % name_DWI) > > ``` > ``` > os.system('dwi2fod csd %s.mif %s_response.txt %s_fod.mif -mask %s_mask.mif' % (name_DWI_2, name_DWI, > > ``` > ``` > os.system('tckgen %s_fod.mif %s_tckgen_%s_%s.tck -seed_image %s_mask.mif -mask %s_mask.mif -algorithm %s %s' % (name_DWI_2, name_DWI_2, algorithm, name, name_DWI, name_DWI, algorithm, opt_1)) > > ``` And I get this image: FACT (wrong labeled before as SD\_Stream): ![](https://community.mrtrix.org/uploads/default/original/1X/3e51589f7667abf0869039b59b585af803f83bae.jpg) SD\_Stream (wrong labeled before as FACT): ![](https://community.mrtrix.org/uploads/default/original/1X/c498ed5889269d28d793c90744c2df89d5eff22f.jpg) Why does it look so? ---
**Author:** ![rsmith](https://community.mrtrix.org/user_avatar/community.mrtrix.org/rsmith/32/2672_2.png) [@rsmith](https://community.mrtrix.org/u/rsmith)\ **Post date:** [February 16, 2017, 12:03am UTC](https://community.mrtrix.org/t/just-ifod1-and-ifod2-works-fact-not/722/2 "2017-02-16T00:03:52Z")
Hi @Ingo, 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](http://mrtrix.readthedocs.io/en/latest/reference/commands/tckgen.html#synopsis). 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`. Cheers Rob ---
**Author:** ![Ingo](https://community.mrtrix.org/letter_avatar_proxy/v4/letter/i/e19adc/32.png) [@Ingo](https://community.mrtrix.org/u/Ingo)\ **Post date:** [February 17, 2017, 9:18am UTC](https://community.mrtrix.org/t/just-ifod1-and-ifod2-works-fact-not/722/3 "2017-02-17T09:18:56Z")
Ok thank you, the labeling was swapped :D. With > fod2fixel %s\_fod.mif -afd %s\_fixel.msf > fixel2voxel %s\_fixel.msf split\_dir %s\_voxel.mif 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: ![](https://community.mrtrix.org/uploads/default/original/1X/feefe34eaf93bb9ae08612be66b793661323a45f.jpg) The new FACT: ![](https://community.mrtrix.org/uploads/default/original/1X/c0d8b8ae3b0faac6efa77f6524ee40a00067b9cf.jpg) ---
**Author:** ![Ingo](https://community.mrtrix.org/letter_avatar_proxy/v4/letter/i/e19adc/32.png) [@Ingo](https://community.mrtrix.org/u/Ingo)\ **Post date:** [February 17, 2017, 9:38am UTC](https://community.mrtrix.org/t/just-ifod1-and-ifod2-works-fact-not/722/4 "2017-02-17T09:38:17Z")
Ok I fixed the SD\_Stream problem. One has to use as option of the tckgen > -angle -77 or another number in this area because if you compare different angles one get: Without any angle option: ![](https://community.mrtrix.org/uploads/default/original/1X/c498ed5889269d28d793c90744c2df89d5eff22f.jpg) With -angle 90: ![](https://community.mrtrix.org/uploads/default/original/1X/0ecde803290350431ada19dca4d07e8795f81c31.jpg) With -angle 77: ![](https://community.mrtrix.org/uploads/default/original/1X/afb0081739b3d0bc72abcad62a1c892ff6bcbfde.jpg) ---
**Author:** ![rsmith](https://community.mrtrix.org/user_avatar/community.mrtrix.org/rsmith/32/2672_2.png) [@rsmith](https://community.mrtrix.org/u/rsmith)\ **Post date:** [February 21, 2017, 10:46pm UTC](https://community.mrtrix.org/t/just-ifod1-and-ifod2-works-fact-not/722/5 "2017-02-21T22:46:00Z")
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? ---
**Author:** ![jdtournier](https://community.mrtrix.org/user_avatar/community.mrtrix.org/jdtournier/32/2594_2.png) [@jdtournier](https://community.mrtrix.org/u/jdtournier)\ **Post date:** [February 22, 2017, 8:50am UTC](https://community.mrtrix.org/t/just-ifod1-and-ifod2-works-fact-not/722/6 "2017-02-22T08:50:31Z")
Yes, @rsmith is spot on. This particular issue is discussed in detail in [this paper](https://www.researchgate.net/publication/264707317_MRtrix_Diffusion_tractography_in_crossing_fiber_regions) (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](http://jdtournier.github.io/mrtrix-0.2/commands/streamtrack.html), 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…? ---
**Author:** ![Ingo](https://community.mrtrix.org/letter_avatar_proxy/v4/letter/i/e19adc/32.png) [@Ingo](https://community.mrtrix.org/u/Ingo)\ **Post date:** [March 6, 2017, 7:11am UTC](https://community.mrtrix.org/t/just-ifod1-and-ifod2-works-fact-not/722/7 "2017-03-06T07:11:35Z")
Sry for my late response but I was in holidays. The 77° was just an arbitrary number 😃 ---
**Author:** ![Ingo](https://community.mrtrix.org/letter_avatar_proxy/v4/letter/i/e19adc/32.png) [@Ingo](https://community.mrtrix.org/u/Ingo)\ **Post date:** [March 6, 2017, 7:14am UTC](https://community.mrtrix.org/t/just-ifod1-and-ifod2-works-fact-not/722/8 "2017-03-06T07:14:32Z")
Can you still help me with the Nulldist2 algorithm as seen above? Why is that image so noisy? ---
**Author:** ![rsmith](https://community.mrtrix.org/user_avatar/community.mrtrix.org/rsmith/32/2672_2.png) [@rsmith](https://community.mrtrix.org/u/rsmith)\ **Post date:** [March 6, 2017, 7:41am UTC](https://community.mrtrix.org/t/just-ifod1-and-ifod2-works-fact-not/722/9 "2017-03-06T07:41:51Z")
Ah sorry, I forgot about that one in my response: 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](http://mrtrix.readthedocs.io/en/latest/reference/commands/tckgen.html#references). ---
**Author:** ![blezek](https://community.mrtrix.org/user_avatar/community.mrtrix.org/blezek/32/453_2.png) [@blezek](https://community.mrtrix.org/u/blezek)\ **Post date:** [April 11, 2017, 8:41pm UTC](https://community.mrtrix.org/t/just-ifod1-and-ifod2-works-fact-not/722/10 "2017-04-11T20:41:23Z")
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: ![](https://community.mrtrix.org/uploads/default/original/1X/374ad53a0a1f781e7a3eb52e2bee8b82ce81155c.png) Compared to the `ifod1` algorithm (with essentially the same parameters): ![](https://community.mrtrix.org/uploads/default/original/1X/733fc423b9413ed62bfad9d42b762d1b386c1b30.png) The I added the `-angle 77` to the `SD_Stream` and got a better result: ![](https://community.mrtrix.org/uploads/default/original/1X/01b6c45a115faf551e5f19e3dd578f7452d35727.png) ---
**Author:** ![jdtournier](https://community.mrtrix.org/user_avatar/community.mrtrix.org/jdtournier/32/2594_2.png) [@jdtournier](https://community.mrtrix.org/u/jdtournier)\ **Post date:** [April 11, 2017, 9:27pm UTC](https://community.mrtrix.org/t/just-ifod1-and-ifod2-works-fact-not/722/11 "2017-04-11T21:27:03Z")
> [@blezek](#): > > So I’m getting the idea that the SD\_Stream algorithm is essentially deprecated in favor of ifod1 and ifod2? 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…). ---
**Author:** ![ThijsDhollander](https://community.mrtrix.org/user_avatar/community.mrtrix.org/thijsdhollander/32/1617_2.png) [@ThijsDhollander](https://community.mrtrix.org/u/ThijsDhollander)\ **Post date:** [April 12, 2017, 6:21am UTC](https://community.mrtrix.org/t/just-ifod1-and-ifod2-works-fact-not/722/12 "2017-04-12T06:21:26Z")
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… ---
**Author:** ![jiangjiane](https://community.mrtrix.org/user_avatar/community.mrtrix.org/jiangjiane/32/1531_2.png) [@jiangjiane](https://community.mrtrix.org/u/jiangjiane)\ **Post date:** [May 27, 2017, 12:59pm UTC](https://community.mrtrix.org/t/just-ifod1-and-ifod2-works-fact-not/722/13 "2017-05-27T12:59:01Z")
Hi @jdtournier, I have a question about above figure: how to generate the 3d images ? Thanks! Best Wishes, Jian ---
**Author:** ![jdtournier](https://community.mrtrix.org/user_avatar/community.mrtrix.org/jdtournier/32/2594_2.png) [@jdtournier](https://community.mrtrix.org/u/jdtournier)\ **Post date:** [May 30, 2017, 3:01pm UTC](https://community.mrtrix.org/t/just-ifod1-and-ifod2-works-fact-not/722/14 "2017-05-30T15:01:25Z")
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… ---
**Author:** ![jiangjiane](https://community.mrtrix.org/user_avatar/community.mrtrix.org/jiangjiane/32/1531_2.png) [@jiangjiane](https://community.mrtrix.org/u/jiangjiane)\ **Post date:** [June 1, 2017, 3:01am UTC](https://community.mrtrix.org/t/just-ifod1-and-ifod2-works-fact-not/722/15 "2017-06-01T03:01:01Z")
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? Thanks! Best Wishes, Jian ---
**Author:** ![jdtournier](https://community.mrtrix.org/user_avatar/community.mrtrix.org/jdtournier/32/2594_2.png) [@jdtournier](https://community.mrtrix.org/u/jdtournier)\ **Post date:** [June 1, 2017, 2:35pm UTC](https://community.mrtrix.org/t/just-ifod1-and-ifod2-works-fact-not/722/16 "2017-06-01T14:35:59Z")
This is the button you’re looking for: ![](https://community.mrtrix.org/uploads/default/original/1X/ab59df6d5160846168471351cd73689324c12013.png) ---
**Author:** ![jiangjiane](https://community.mrtrix.org/user_avatar/community.mrtrix.org/jiangjiane/32/1531_2.png) [@jiangjiane](https://community.mrtrix.org/u/jiangjiane)\ **Post date:** [June 3, 2017, 12:20pm UTC](https://community.mrtrix.org/t/just-ifod1-and-ifod2-works-fact-not/722/17 "2017-06-03T12:20:49Z")
Hi @jdtournier , Thank you for your detailed answer! Best Wishes, Jian ---
**Author:** ![Vinny](https://community.mrtrix.org/user_avatar/community.mrtrix.org/vinny/32/3434_2.png) [@Vinny](https://community.mrtrix.org/u/Vinny)\ **Post date:** [July 6, 2021, 11:52pm UTC](https://community.mrtrix.org/t/just-ifod1-and-ifod2-works-fact-not/722/18 "2021-07-06T23:52:08Z")
Hello, I would like to use the FACT algorithm as well and tried the above methodology but to no success. Here were the following steps: dwi2fod csd eddy.mif wm\_response.txt fod.mif -mask eddy\_mask.mif fod2fixel fod.mif fixel.msf I had to ‘cd’ into the fixel directory since the fixel.msf was not accepted as an input for fixel2voxel. fixel2voxel directions.mif none voxel.mif tckgen voxel.mif dti.tck -algorithm FACT -seed\_image eddy\_mask.mif -mask eddy\_mask.mif -select 5000000 Output: tckgen: [ERROR] Number of volumes in FACT algorithm input image should be a multiple of 3 Any help would be appreciated. Thanks, Vinny ---
**Author:** ![Vinny](https://community.mrtrix.org/user_avatar/community.mrtrix.org/vinny/32/3434_2.png) [@Vinny](https://community.mrtrix.org/u/Vinny)\ **Post date:** [August 11, 2021, 11:56am UTC](https://community.mrtrix.org/t/just-ifod1-and-ifod2-works-fact-not/722/19 "2021-08-11T11:56:42Z")
Hello, 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. I’m assuming this is CSD followed by FACT. Regards, Vinny