# Unwanted results using ACT tractography with HCP data **URL:** \ **Category:** Uncategorized\ **Created:** [April 2, 2019, 1:23pm UTC](https://community.mrtrix.org/t/unwanted-results-using-act-tractography-with-hcp-data/2419 "2019-04-02T13:23:27Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![cbajada](https://community.mrtrix.org/user_avatar/community.mrtrix.org/cbajada/32/1390_2.png) [@cbajada](https://community.mrtrix.org/u/cbajada)\ **Post date:** [April 2, 2019, 1:23pm UTC](https://community.mrtrix.org/t/unwanted-results-using-act-tractography-with-hcp-data/2419/1 "2019-04-02T13:23:27Z")
I wanted to report an issue that I’ve come across while working with HCP data and MRtrix3. The Human Connectome Project has high quality dMRI data which makes it very appealing to use for tractography studies. Unfortunately, due to the way these data are preprocessed, performing tractography on HCP data with anatomically constrained tractography (ACT) can give some unwanted results. One such issue that can arise, which has not to my knowledge been reported, is due to the fact that the HCP diffusion data are rigidly transformed to their ACPC aligned space. A by-product of this processing step is that the brainstem may be truncated _before_ reaching the edge of the field of view (FoV). I will demonstrate the problem below. The data I used was the standard minimally preprocessed HCP data (this example is with participant `100206` ). I will provide the commands used so that anyone else can replicate the error (and potential fixes). **The Problem** As I already mentioned, in the minimally preprocessed HCP data, the DWI volumes are rigidly transformed to the anatomical space, rather than the usual practice of registering the T1w image to the DWI volumes. During this transformation, any voxel in the _target image_ for which there is not a valid location in the _input image FoV_ from which to “pull” image intensities will be filled with zeroes. As a result, the `dwi2fod` command will populate such voxels with FODs consisting of zeroed coefficients (regardless of whether or not a mask is explicitly provided to `dwi2fod` ). This has important ramifications for the inferior part of the brainstem in the context of ACT. While in the acquired DWI data there will be valid image intensities all the way to the inferior-most slice of the image FoV, upon transformation to the ACPC space, this “lower edge” of the brainstem (as defined by the diffusion MRI FoV) will no longer lie at the outer edge of the image FoV. Thus, when a streamline traverses in the inferior direction in this region, it will eventually encounter those voxels where the FODs have zero amplitude, and thus terminate within the brainstem due to the `tckgen` FOD amplitude threshold. Since the ACT image is generated from the T1w image, which very often has more brainstem in its FoV, the streamlines will be interpreted by ACT to have terminated in white matter, and will therefore be _ **excluded** _ . Here is an image of the extent of the DWI image (red overlay) versus the 5TT image (grey): ![image.jpg](https://community.mrtrix.org/uploads/default/original/2X/3/3bc125081118b184147dfc6ecc3e897e6f74e2a1.jpeg) Running tckgen with ACT on these data using this command: `tckgen WM_FODs.mif -seed_sphere 0,-33,-47,10 -seed_dir 0,0,1 -select 1k -act 5TT.mif test_act.tck` Causes this problem: ![test_act.png](https://community.mrtrix.org/uploads/default/original/2X/2/25efc26d17d2bea79e40c30b7aa59af2c89918aa.png) As you can see above, the streamlines that terminate on leaving the brainstem are excluded from the `.tck` file. Note that the streamlines that are visible here are those that terminate in areas of the brainstem that are labeled (potentially mislabeled) as grey matter. **Workarounds** The possible solutions to the problem are various (and rather simple) but none are necessarily “ideal”. The issue should be fixed in the upcoming version of _MRtrix3_ , but until then, these workarounds could be used. **a) Using the `-mask` option in `tckgen`** The HCP provides a file called `nodif_brain_mask` . This handy volume contains a mask of all the voxels that have valid diffusion data. The `tckgen` command can therefore be run providing this image using the `-mask` option: `tckgen WM_FODs.mif -seed_sphere 0,-33,-47,10 -seed_dir 0,0,1 -select 1k -act 5TT.mif test_act_mask.tck -mask nodif_brain_mask.nii.gz` ![test_act_mask.png](https://community.mrtrix.org/uploads/default/original/2X/6/67cae83ee51bed6f7c33359ccc0dd788e72108f4.png) As you can see this solves the greater part of the problem. This is possible because providing a 5TT image in order to perform ACT, and providing one or more mask images to constrain where streamlines are permitted to exist, are in fact _not mutually exclusive_ . Note that premasking the ACT image with the diffusion mask has the same effect. **b) Replacing the zeros in the WM\_FODs with NaNs** Using the following command, you can explicitly set any voxel with a value of exactly zero to be considered as “not a number” (“NaN”): `mrconvert WM_FODs.mif -coord 3 0 - | mrcalc - 0 -neq WM_FODs.mif nan -if WM_FODs_nan.mif` This results in FODs outside of the brain volume containing “illegal” values (rather than zero values), and is also a potential fix to the problem, since streamlines traversing this region will be terminated due to “absence of valid FOD data” (rather than FOD amplitudes becoming progressively smaller): `tckgen WM_FODs_nan.mif -seed_sphere 0,-33,-47,10 -seed_dir 0,0,1 -select 1k -act 5TT.mif test_act_nan.tck` ![test_act_nan.png](https://community.mrtrix.org/uploads/default/original/2X/0/0315d03491309a07174f24f502d17f3ff8170167.png) **c) Not using ACT** Finally, although this is not the recommended approach, not using ACT in the first place will also work! `tckgen WM_FODs.mif -seed_sphere 0,-33,-47,10 -seed_dir 0,0,1 -select 1k test_noact.tck` ![test_noact.png](https://community.mrtrix.org/uploads/default/original/2X/7/7315a46da6e5304de1d070a341fcb6c9f65c7922.png) Due to the nature of the HCP data, this error occurs in a high proportion of subjects, and will of course extend to any data that share the same properties (ie brainstem not at the bottom of the FOV). ---
**Author:** ![mblesac](https://community.mrtrix.org/user_avatar/community.mrtrix.org/mblesac/32/2210_2.png) [@mblesac](https://community.mrtrix.org/u/mblesac)\ **Post date:** [September 17, 2020, 10:44am UTC](https://community.mrtrix.org/t/unwanted-results-using-act-tractography-with-hcp-data/2419/2 "2020-09-17T10:44:46Z")
Hi, After reading this topic I decided to use the option `-mask` with `-act` to process the HCP data. However, I was wondering is this the recommended approach for this data? and what could be the effect of using or not the` -mask` option in the whole brain tractography? Best regards, Manuel ---
**Author:** ![cbajada](https://community.mrtrix.org/user_avatar/community.mrtrix.org/cbajada/32/1390_2.png) [@cbajada](https://community.mrtrix.org/u/cbajada)\ **Post date:** [September 17, 2020, 12:03pm UTC](https://community.mrtrix.org/t/unwanted-results-using-act-tractography-with-hcp-data/2419/3 "2020-09-17T12:03:58Z")
Hi @mblesac, @rsmith can confirm but I think this bug was fixed in the more recent versions of MRtrix3. You could easily test this by replicating the commands above and seeing if the brainstem streamlines are preserved. Re: using the `-mask` option on whole brain tractography, assuming your mask is well defined (has no holes, covers the whole brain etc…) I do not think it will have much of an negative impact. But you will have an additional bit of QC to be doing! If the issue was fixed (which I strongly suspect that it has) then the `-mask` option would add no benefit (that I can see). Claude ---
**Author:** ![mblesac](https://community.mrtrix.org/user_avatar/community.mrtrix.org/mblesac/32/2210_2.png) [@mblesac](https://community.mrtrix.org/u/mblesac)\ **Post date:** [September 17, 2020, 12:13pm UTC](https://community.mrtrix.org/t/unwanted-results-using-act-tractography-with-hcp-data/2419/4 "2020-09-17T12:13:46Z")
Hi @cbajada, Thanks your reply! I’m using an old version of mrtrix (`MRtrix 3.0_RC3-15-g9494da8d`), so probably the issue still persists. I only processed the HCP data, so all the masks are good. Best regards, Manuel ---
**Author:** ![cbajada](https://community.mrtrix.org/user_avatar/community.mrtrix.org/cbajada/32/1390_2.png) [@cbajada](https://community.mrtrix.org/u/cbajada)\ **Post date:** [September 18, 2020, 9:47am UTC](https://community.mrtrix.org/t/unwanted-results-using-act-tractography-with-hcp-data/2419/5 "2020-09-18T09:47:11Z")
Hmm… assuming that the issue was not fixed by version `3.0_RC3-15-g9494da8d`, then I would go for the `-mask` option as you have done. I would also make sure to look at the resultant tracts (or a density image derived from the full brain tractography) just to ensure that you are getting sensible results. The `-mask` option should simply confine the tractography to the defined mask: > -mask spec (multiple uses permitted) > specify a masking region of interest, as either a binary mask image, or as > a sphere using 4 comma-separared values (x,y,z,radius). If defined, > streamlines exiting the mask will be truncated. So as long as the mask is well defined, I don’t envisage any issues. ---
**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:** [September 30, 2020, 12:56pm UTC](https://community.mrtrix.org/t/unwanted-results-using-act-tractography-with-hcp-data/2419/6 "2020-09-30T12:56:43Z")
Unfortunately the issue hadn’t been fixed – until now… Thanks for the reminder, this had totally fallen off our radar. @rsmith has now [added a fix](https://github.com/MRtrix3/mrtrix3/pull/2180), which will be available very shortly in the next release.