Streamlines tractography output problem

[SuperClear]

Hi, all,

Have you ever meet this problem? I did streamlines tractography and the output seems abnormal.
Here is the code:

tckgen -algorithm SD_Stream -cutoff 0.25  -angle 77 DTI_fod.mif DTI_StreamTracking_FA0.25_ang77.tck -seed_grid_per_voxel DTI_mask.nii 1 -mask DTI_mask.nii

and the outputs as are shown:
Ortho View:

Volume Rendering:

The fibers of the other papers:

In volume rendering view: In the left and right white rectangles, the fibers have many short fibers perpendicular to the others. What I consider most is the white rectangle in the bottom, compared with the third picture, there are sets of red transversal fibers. It seems there are some fibers just lay down on the surface of the brain cortex.

Maybe there’s some problem when I do streamline tractography. I have no idea now, does anyone have some ideas?

Thanks,
Chaoqing

[jdtournier]

There’s nothing that unusual about your results. I personally don’t recommend using deterministic tractography (which the sd_stream algorithm is), for a whole number of reasons, which I won’t go into here. But at least you’re using sensible parameters with it (reminds me that we still need to fix up the default angle parameter - I’ll do that ASAP).

The spurious streamlines that you see through cortical regions are also not unexpected particularly when using lower b-values (I assume this is using b = 1000 s/mm² data?). This is the kind of issue that ACT was designed to deal with, I strongly recommend you consider adding that approach to your workflow. There are other approaches to minimise the occurrence of these issues (higher b-values, using a white matter mask, …), but none of them are as good as using ACT itself.

One slight concern is that the spurious fibres seem to run predominantly in the AP direction, which could indicate a systematic bias, maybe due to eddy currents or some other subtle instability. Best thing to do to verify this would be to run your acquisition protocol on a phantom and check that the anisotropy is near zero and the primary eigenvector direction is genuinely random (you’ll need to use a slow diffusing phantom for this, e.g. agar, not water, otherwise you’ll get no signal in the DWIs…).

[ThijsDhollander]

@SuperClear

It seems there are some fibers just lay down on the surface of the brain cortex.

@jdtournier

One slight concern is that the spurious fibres seem to run predominantly in the AP direction

Those in the AP direction are mostly those at the left/right sides, right? Not per se AP direction over the whole brain? That’s consistent with the “laying down on the surface of the brain” bit… which could potentially also suggest a problem with motion between volumes? Have you done proper motion correction across the series of images?

[SuperClear]

Yeah, right, the b-value is 1000s/mm². And the data comes from the hospital, I really don’t know how to verify this…

I’m going to see how to use ACT. I almost don’t know anything about ACT.

Thanks for your suggestion~~ grinning:

[SuperClear]

Yeah, the transversal fibres are just on the left side or on the right side. They are not per se AP direction over the whole brain. In fact, I didn’t do any motion correction across the images, probably, the reflect the problem with motion. I didn’t take it into account …

[rsmith]

Throwing a few more thoughts into the hat:

• Other softwares / articles commonly use a more conservative tracking threshold, e.g. FA > 0.2; MRtrix3 defaults to FOD amplitude > 0.1. This will result in generation of streamlines in areas where other algorithms would forbid them, but also reduces the prevalence of false terminations.

• Other softwares / articles also commonly use a longer minimum length criterion, e.g. 20-30mm; MRtrix3 defaults to 5 voxels (~ 10mm). This permits reconstruction of short connections that do exist in the brain, but can appear “noisy”, whereas other algorithms put an emphasis on reconstruction of the major white matter bundles only.

• CSD is more sensitive to both crossing fibre populations with small volume, and more complex fibre configurations, than many other models. But as previously, this can also appear as “noisy” streamlines reconstruction.

The second image you provided uses red for AP direction and green for LR direction; it’s very off-putting

The spurious streamlines that you see through cortical regions are also not unexpected particularly when using lower b-values (I assume this is using b = 1000 s/mm² data?). This is the kind of issue that ACT was designed to deal with, I strongly recommend you consider adding that approach to your workflow. There are other approaches to minimise the occurrence of these issues (higher b-values, using a white matter mask, …), but none of them are as good as using ACT itself.

Throwing multi-tissue CSD into the mix here as well. By assigning the signal emanating from grey matter to grey matter, and only using the anisotropic white matter signal contribution for tracking, streamlines at / near the cortex are more reliable and “clean-looking”, since in single-tissue CSD the approximately isotropic grey matter signal results in non-isotropic noise-sensitive FODs.

[SuperClear]

Cool!

Thanks for your deep analysis. I benefit a lot from your explanation.

[SuperClear]

Hi, Donald,

I mainly test ACT method on two data sets, and what I concerned most are the following two points:

1. The corpus callosum fibers are incomplete, as shown in Fig.1-5 and Fig 2-5.
2. The tckgen results a lot of short fibers, as shown in Fig 1-4.

I also had tried:
A) increase fiber number: up to 1M;
B) Change mask: white matter mask → whole brain mask.
C) seeding mechanisms: -seed_dynamic and -seed_gmwmi

But the comeout has no any improvement.
Can you provide me some suggestion?

Thanks,
Chaoqing

---

1. ACT with data1

I register DTI and T1 to MNI152 space as Lucius suggested.

Fig. 1-0. ( mrview: T1, DTI, WM, GMWMI in MNI152 space)

Fig. 1-1. ( response function )

Fig. 1-2. (white matter mask)

Fig. 1-3. (Fiber orientation distribution)

Fig. 1-4. (tckgen -act result)

Fig. 1-5. (The rendering result)

[ACT commands]:

1. 5ttgen fsl t1_2013_freesufer_in_MNI152.nii.gz t1_2013_freesufer_in_MNI152_nocrop_5TT.nii.gz -nocrop

2. 5tt2gmwmi t1_2013_freesufer_in_MNI152_nocrop_5TT.nii.gz t1_2013_freesufe
   r_in_MNI152_nocrop_5TT_gmwmi.mif

3. dwi2response tournier DTI_2013_freesurfer_in_MNI152.nii.gz DTI_2013_free
   surfer_in_MNI152_fswm_response.txt -mask t1_2013_freesufer_wm_in_MNI152.nii.gz -fslgrad DTI_2013.bvecs DTI_2013.bvals

4. dwi2fod csd DTI_2013_freesurfer_in_MNI152.nii.gz DTI_2013_freesurfer_in_
   MNI152_fswm_response.txt DTI_2013_freesurfer_in_MNI152_fswm_fod.mif -mask t1_2013_freesufer_wm_in_MNI152.nii.gz -fslgrad DTI_2013.bvecs DTI_2013.bvals

5. tckgen -act t1_2013_freesufer_in_MNI152_nocrop_5TT.nii.gz DTI_2013_free
   surfer_in_MNI152_fswm_fod.mif DTI_2013_freesurfer_in_MNI152_fswm_act_gmwmi_backtrack_0.1M.tck -crop_at_gmwmi -seed_gmwmi t1_2013_freesufer_wm_in_MNI152.nii.gz -backtrack -select 100000

---

2. ACT with data2(An example data)

Fig. 2-0 ( mrview: T1, DTI, WM, GMWMI )

Fig. 2-1. ( response function )

Fig. 2-3. (Fiber orientation distribution)

Fig. 2-4. (tckgen -act result)

Fig. 2-5. (The rendering result)

[ACT commands]:

1. 5ttgen fsl T1_HARDI150.nii.gz T1_HARDI150_5TT_nocrop.mif -nocrop

2. dwi2response tournier -fslgrad HARDI150.bvec HARDI150.bval HARDI150.nii.gz HARDI150_response.txt

3. dwi2fod csd HARDI150.nii.gz HARDI150_response.txt HARDI150_WMvolume_fod.mif -mask T1_HARDI150_5TT_nocrop_WMvolume_3D_HARDItemplate.nii.gz -fslgrad HARDI150.bvec HARDI150.bval

4. 5tt2gmwmi T1_HARDI150_5TT_nocrop.mif T1_HARDI150_5TT_nocrop_gmwmi.mif

5. tckgen -act T1_HARDI150_5TT_nocrop.mif HARDI150_WMvolume_fod.mif HARDI150_Wmvolume_act_0.1M_backtrck.tck -crop_at_gmwmi -seed_gmwmi T1_HARDI150_5TT_nocrop_gmwmi.mif -backtrack -select 100000

---

[jdtournier]

OK, for Data1, it’s hard to tell, but there’s a few things to look at:

• what do the WM ODFs (HARDI150_WMvolume_fod.mif) look like in the corpus callosum in those problematic regions?
• what does the 5TT image (T1_HARDI150_5TT_nocrop.mif) look like in the same region?
• are you sure your WM ODFs are correctly oriented? It’s hard to tell from your screenshot, but given what you show in Data2, there’s a good chance that’s where the problem is (see below).

For Data2, your figure 2-3 very clearly shows that either the X or Y component has been inverted - your FODs don’t point in the expected anatomical directions. This means there’s a problem with your gradient table import. Where did your DTI_2013.bvecs come from? I think that’s the issue…

Assuming you’re confident that your bvecs are correct, one possible explanation would be this previous bug, long since fixed. If that’s the case, you might be able to deal with this by inverting the strides for the X component of your DTI_2013_freesurfer_in_MNI152.nii.gz image, but that very much depends what the strides are currently. Assuming

mrinfo DTI_2013_freesurfer_in_MNI152.nii.gz -stride

outputs 1 2 3 4, then try

mrconvert DTI_2013_freesurfer_in_MNI152.nii.gz -stride -1,2,3,4 DTI_2013_freesurfer_in_MNI152_new.nii.gz

and use that file for the subsequent processing, there’s a chance that might fix it… Note that this relies on an up to date version of MRtrix3 (i.e. one that correctly handles the FSL bvecs).

[SuperClear]

Hi, Rob,

I have some puzzles on SD_STREAM determination tractography:

The tckgen results are hard fibers(Fig. 3-1 and Fig.3-2), especially comared with Fig. 4-1 and Fig. 4-2.

Do you know what may cause the problem? Do we need to do fiber smooth operation?

Also,I tried:
A) change masks: the whole brain mask, WM mask created by FreeSurfer.
B) change seeding mechanisms: -seed_dynamic and -seed_image mask
C) change angles: 30 - 45.
However, the outputs have the same problem.

Thanks,
Chaoqing

---

The data that I use is the example data ( as shown previously in the current topic: “ACT with data2”

Here are the rendering of the determination tractography output:

Fig. 3-1( axial view )

Fig. 3-2( sagittal view )

[SD_Stream commands]:

1. 5ttgen fsl T1_HARDI150.nii.gz T1_HARDI150_5TT_nocrop.mif -nocrop

2. mrconvert -coord 3 2 T1_HARDI150_5TT_nocrop.mif T1_HARDI150_5TT_nocrop WMvolume.nii.gz

3. mrmath T1_HARDI150_5TT_nocrop_WMvolume.nii.gz mean -axis 3 T1_HARDI150_5TT_nocrop_Wmvolume_3D.nii.gz

4. mrtransform T1_HARDI150_5TT_nocrop_WMvolume_3D.nii.gz -template HARDI150.nii.gz T1_HARDI150_5TT_nocrop_Wmvolume_3D_HARDItemplate.nii.gz

5. dwi2response tournier -fslgrad HARDI150.bvec HARDI150.bval HARDI150.nii.gz HARDI150_response.txt (shview HARDI150_response.txt)

6. dwi2fod csd HARDI150.nii.gz HARDI150_response.txt HARDI150_WMvolume_fod.mif -mask T1_HARDI150_5TT_nocrop_WMvolume_3D_HARDItemplate.nii.gz -fslgrad HARDI150.bvec HARDI150.bval

7. tckgen -algorithm SD_Stream HARDI150_WMvolume_fod.mif HARDI150_WMvolume_StreamTracking_pervoxel.tck -seed_grid_per_voxel T1_HARDI150_5TT_nocrop_WMvolume_3D_HARDItemplate.nii.gz 2 -mask T1_HARDI150_5TT_nocrop_Wmvolume_3D_HARDItemplate.nii.gz -minlength 10

---

Fiber tracking result from Zhejiang University of Technology with the same data.
I don’t know the specific algorithm of them, just get the data from them, and the rendering results looks cool.

Fig. 4-1 (axial view )

Fig. 4-2 ( sagittal view )

[Lucius]

@jdtournier

I personally don’t recommend using deterministic tractography (which the sd_stream algorithm is), for a whole number of reasons, which I won’t go into here.

Dear @jdtournier, we’re quite interested in that specific topic. In the clinical setting, the neuronavigation applications use determistic tractography algorithms (I think Brainlab uses a mixture between FACT and TEND). I prefer to have at least a comparison of probabilistic and deterministic based results to get a better overview over the patients wm structure. To overcome that problem, I sometimes burn the probabilistic tracts on a dicom set and then feed it to the planning software (unfortunately not a straight forward process) or just use the images then.

Since at our clinic most of the colleagues are familiar with a deterministic algorithm but usually not with the probabilistic ones, it’s not always easy to implement it.

So, to work on the general acceptance and familiarity, it would be wonderful if you could provide a few good arguments for prob. tractography and some reasons why not to (only) use det tractography.
Or if anyone knows about good papers concerning that topic, I’d be very thankful as well.

Best regards and thanks for your much appreciated mrtrix!
Lucius

[jdtournier]

@SuperClear

The tckgen results are hard fibers(Fig. 3-1 and Fig.3-2), especially comared with Fig. 4-1 and Fig. 4-2.

I’m not sure what you mean by ‘hard fibers’ here, but I expect you mean they look a bit ‘blocky’ - for want of a better word? That’s actually part of the reason why I don’t recommend the use of the deterministic streamlines algorithm on SH fods - see this paper, particularly Figure 2, for an description of (one of) the problems. Assuming the other images were also generated using MRtrix3 (don’t know whether this is in fact the case?), then the default algorithm, iFOD2, would give you results similar to this (with decent input data) - it’s probabilistic, which I do recommend for the reasons outlined in the same MRtrix paper as above.

[jdtournier]

@Lucius

So, to work on the general acceptance and familiarity, it would be wonderful if you could provide a few good arguments for prob. tractography and some reasons why not to (only) use det tractography.

I appreciate your situation… This is an argument that I’ve had many times in the past, and it’s still far from resolved. My point of view has always been that there are many sources of uncertainty in diffusion MRI: noise of course, but more importantly also the inevitable fibre dispersion (due to fanning, curvature, crossings, but also jitter in the individual axon trajectories), and the inherent blurring effect of the diffusion measurement (its angular resolution is limited by the inherent smoothness of the diffusion profile / response function). Deterministic streamlines ignores all sources of uncertainty and reports the single ‘best guess’. This runs an enormous risk of missing existing connections – i.e. high false negatives.

For an application as critical as neurosurgery planning, I would argue that such false negatives are very dangerous: this would give the surgeon a false sense of security, implying for example that no eloquent white matter pathways run though the planned resection, leading to otherwise avoidable loss of function (e.g. this paper). So from this point of view, I would always advocate probabilistic tractography since it is designed to produce the full distribution of likely pathways.

Note that this undeniably involves many more false positives (see this paper on the topic). This is often stated as a drawback, making the results messier and harder to interpret. However, I would argue that it is better to provide surgeons with the fullest possible picture of the likely tracks in the region, from which they can then make informed decisions about what is plausible and what isn’t. The alternative (deterministic tracrography) is to present results known to be potentially incomplete – a strategy I’d personally consider to be reckless and indefensible.

As to relevant publications on the topic, you’re in luck: this just came out… See figure 3 in particular. Also relevant, this paper comparing DTI and CSD based tractography might be of interest – it does make a subtly different point from what you’re asking, but the issue of probabilistic vs. deterministic is also discussed. I’ve no doubt there may be other relevant papers out there, these are just a couple to get you started. Hopefully other users will point out a few more…

[Lucius]

Thank you very much for this great explanations, arguments and links. The users and developers of planning software should really know more and about those issues and consider solutions.

[SuperClear]

Hi, Donald,

1. ACT with data2(An example data)

The FODs ( HARDI150_WMvolume_fod.mif ) is not in expected anatomical directions(as shown in Fig. 5.1).
The 5TT image (T1_HARDI150_5TT_nocrop.mif) is shown in Fig.5.2.
However, I cannot fix it by using mrconvert -stride command, I tried:

mrconvert HARDI150.nii.gz -stride -1,2,3,4 HARDI150_StrideX.nii.gz ( Fig.5.3 )
mrconvert HARDI150.nii.gz -stride 1,-2,3,4 HARDI150_StrideY.nii.gz ( Fig.5.4 )
mrconvert HARDI150.nii.gz -stride -1,-2,3,4 HARDI150_StrideXY.nii.gz ( Fig.5.5 )

I finally fix HARDI150 FODs by inverse the second column of HARDI150.bvecs as shown in Fig 5.6 ( HARDI150.bvecs maybe not generated by Mrtrix3 ). Fig 5.7 shown the corpus callosum region. However, it is not able to generate the fibers in corpus callosum region( see Fig 5.9 and Fig 5.10 ).

Do you have any ideas? I still cannot find the solution.

---

2. ACT with data1

The DTI_2013.bvecs is created by Mrtrix3 command:
mrconvert 2013-02-06_10_56_37.0/ -export_grad_fsl DTI_2013.bvecs DTI_2013_bvals DTI_2013.nii.gz

① In native anatomical space:
DTI_2013.nii.gz is 4D image and t1_2013.nii.gz is the corresponding 3D image. I use the original data: ( DTI_2013.nii.gz / t1_2013.nii.gz ) to generate the fod image ( DTI_2013_fod.mif ) , the fod image correctly shows the anatomical direction, see Fig 6.1.

Then I do recon-all command of FreeSurfer to generate cortical parcellations of t1_2013.nii.gz. In this way, the t1_2013.nii.gz data will naturally go to FreeSurface space ( t1_2013_freesurfer.nii.gz ) . So I register DTI_2013.nii.gz to DTI_2013_freesurfer.nii.gz, following Lucius’s instruction, They seems registered nicely, see Fig 6.2:

A. Register DTI_b0 to T1_freesurfer:

flirt -in DTI_2013_b0.nii.gz -ref t1_2013_freesufer_skulled.nii.gz -omat DTI_2013_b0_to_t1_2013_freesurf_skulled.mat

flirt -in DTI_2013_b0.nii.gz -ref t1_2013_freesufer_skulled.nii.gz -applyxfm -init DTI_2013_b0_to_t1_2013_freesurf_skulled.mat -out DTI_2013_b0_freesurfer.nii.gz

B. Register DTI to T1_freesurfer:

flirt -in DTI_2013.nii.gz -ref t1_2013_freesufer_skulled.nii.gz -applyxfm -init DTI_2013_b0_to_t1_2013_freesurf_skulled.mat -out DTI_2013_freesurfer.nii.gz

② In FreeSurfer space:
I use the data ( DTI_2013_freesurfer.nii.gz/ t1_2013_freesurfer.nii.gz ) to generate the fod image (DTI_2013_freesurfer_fod.mif), From then on, the fod image can not correctly indicate the anatomical direction, see Fig 6.3. You can find the tensors on the top half the region of corpus callosum are incorrect. (It seems half of the orientation is correct and the other half goes wrong).

③ In MNI152 space:
Then I use the similar registration command to register (DTI_2013_freesurfer.nii.gz/ t1_2013_freesurfer.nii.gz) to MNI152 space. The fod image ( DTI_2013_freesurfer_in_MNI152_fswm_fod.mif ) certainly incorrectly indicates the anatomical direction, as shown in Fig 1.3.

Does it mean I did wrong registration? I tried mrconvert -stride and inverse the second collum of bvecs, the output fod images maintain wrong. I hope to know how does it happen and expect to figure it out.

Sweet Thanks,
Chaoqing

---

Fig 5.1 ( HARDI150_WMvolume_fod.mif )

Fig 5.2 ( T1_HARDI150_5TT_nocrop.mif )

Fig 5.3 ( HARDI150_StrideX_WMvolume_fod.mif )

Fig 5.4 ( HARDI150_StrideY_WMvolume_fod.mif )

Fig 5.5 (HARDI150_StrideXY_WMvolume_fod.mif )

Fig 5.6 (HARDI150_bvecInverseY_WMvolume_fod.mif )

Fig 5.7 (HARDI150_bvecInverseY_WMvolume_fod.mif )

Fig 5.8
( T1_HARDI150_5TT_nocrop.mif and T1_HARDI150_5TT_nocrop_WMvolume_3D_HARDItemplate.nii.gz )

Fig 5.9 ( HARDI150_bvecInverseY_WMvolume_act_0.1M_backtrack.tck )

Fig 5.10 ( HARDI150_bvecInverseY_WMvolume_act_0.1M_backtrack.tck )

[ACT commands]:

1. dwi2response tournier -fslgrad HARDI150_InverseY.bvecs HARDI150.bvals HARDI150.nii.gz HARDI150_bvecInverseY_response.txt

2. dwi2fod csd HARDI150.nii.gz HARDI150_bvecInverseY_response.txt HARDI150_bvecInverseY_WMvolume_fod.mif -mask T1_HARDI150_5TT_nocrop_WMvolume_3D_HARDItemplate.nii.gz -fslgrad HARDI150_InverseY.bvecs HARDI150.bvals

3. tckgen -act T1_HARDI150_5TT_nocrop.mif HARDI150_bvecInverseY_WMvolume_fod.mif HARDI150_bvecInverseY_WMvolume_act_0.1M_backtrack.tck -crop_at_gmwmi -seed_gmwmi T1_HARDI150_5TT_nocrop_gmwmi.mif -backtrack -select 100000

---

Fig 6.1 ( DTI_2013_fod )

Fig. 6.2 ( mrview : T1, DTI, WM, 5TT image in FreeSurfer space)

Fig 6.3 ( DTI_2013_freesurfer_fod.mif )

---

[jdtournier]

OK, there’s two issues there:

• It seems your Data2 raw data was converted outside of MRtrix3? There’s not a lot we can do to fix invalid input data… If this was DICOM format, I’d be willing to look into it, since we take great care to ensure the conversion works as expected for all major manufacturers. But as soon as it’s been converted, it’s pretty much impossible to ensure any subsequent correction actually does the right thing. I strongly recommend starting again from the raw DICOM of you can possibly get access to it.

  In your case, it does look like inverting the Y might be sufficient, but it’s not guaranteed if the data are potentially acquired in an oblique orientation. Maybe you can use @bjeurissen’s dwigradcheck and see what that tells you.

• for your Data1 case, the main thing is to never transform FOD data (or DWI data in general). These images contain orientation information, and the relationship that information relative to the orientation of the anatomy or scanner will be affected if you reorient the images. Dealing with this requires dedicated handling of the information in the images. Basically, the simplest thing to do to avoid issues is to never transform any DWI or derived data, unless you know the tool you’re using to do this is designed to handle this exact type of data (most won’t). Already register the T1 to the DWI, never the other way round…

[rsmith]

However, I cannot fix it by using mrconvert -stride command, I tried:

The -stride option in mrconvert only affects how data from different image axes are arranged into a 1D vector of data for storage in RAM / on a file system. Therefore use of this option will not affect the orientations of different spatial axes relative to one another, or the orientations of any voxel-wise directional information, assuming the images are both written and read by MRtrix3. This can have an influence if the images are opened using other softwares, but that depends on how different softwares interpret image heaer transformation information.

[SuperClear]

Hi, Donald,

Thank you very much for your patient explanation!

In my data2 case, I feel very glad to shall the data, but I can’t find the raw DICOM data in my lab, It seems we have lost the raw DICOM data. Or maybe, we didn’t get the original raw data at the beginning. However, if needed, feel free to get the NIFTI data and corresponding T1 data with the dropbox link below.

In my data1 case, I should not transform DWI data to another space, as you said it will damage the original orientation information. So, I try to warp tck file, the corresponding FA image to MNI152 space.

In order to test the warping method, I almost copy Eloy’s steps. All the steps go without any error. However, there are quite a lot straight lines along with the fibers, especially from the sagittal view ( Fig 7.1 , data1), which is quite different from the warped result with the same steps of data3 (Fig 7.2, data3). Are there any restrictive conditions on warping the images? I guess the problem should hide in my data1.

Also, Comparing with the tck file in subject space, the tck file warped to MNI152 space reserved the same streamline numbers and point numbers. However, the length of each streamline changed. Also, the fa value of each point is quite different from the original value in subject space. Is there any method to preserve the original information after warping to MNI152 space?

A lot of Thanks,
Chaoqing

---

The dropbox link to HARDI150 data:

HARDI150

The warping steps of data 1:

1. fslchfiletype NIFTI MNI152_T1_1mm.nii.gz

2. ANTS 3 -m CC[MNI152_T1_1mm.nii, t1_2013.nii.gz,1,5] -t SyN[0.5] -r Gauss[2,0] -o T1_to_MNI_synants.nii -i 30x90x20 --use-Histogram-Matching

3. warpinit MNI152_T1_1mm.nii flirtMNI-.nii

4. for i in {0…2}
   do
   WarpImageMultiTransform 3 flirtMNI-{i}.nii flirtMNI2tck-{i}.nii -R MNI152_T1_1mm.nii -i T1_to_MNI_synantsAffine.txt T1_to_MNI_synantsInverseWarp.nii
   done

5. warpcorrect flirtMNI2tck-.nii flirtMNI2tck_corr.mif

6. tcknormalise DTI_2013_act_0.5M.tck flirtMNI2tck_corr
   .mif DTI_2013_act_0.5M_WarpMNI152.tck

Fig 7.1 ( data1 warped tckfile ):

Fig 7.2 (data3 warped tckfile):

The warping steps of data 3 and FA value sampling.

1. ANTS 3 -m CC[MNI152_T1_1mm.nii, t1_mpr_ns_sag_iso.nii.gz, 1, 5] -t SyN[0.5] -r Gauss[2,0] -o t1_disease_liuyan_to_MNI_synants.nii -i 30x90x20 --use-Histogram-Matching

2. warpinit MNI152_T1_1mm.nii flirtMNI-.nii

3. for i in {0…2}; do WarpImageMultiTransform 3 flirtMNI-{i}.nii flirtMNI2_disease_liuyan_tck-{i}.nii -R MNI152_T1_1mm.nii -i t1_disease_liuyan_to_MNI_synantsAffine.txt t1_disease_liuyan_to_MNI_synantsInverseWarp.nii ; done

4. warpcorrect flirtMNI2_disease_liuyan_tck-.nii flirtMNI2_disease_liuyan_tck_corr.mif

5. tcknormalise DTI_30_average-6_act_sift_0.2M.tck flirtMNI2_disease_liuyan_tck_corr.mif DTI_30_average-6_act_sift_0.2M_warpMNI152.tck

6. dwi2tensor –mask DTI_30_average-6_mask.nii DTI_30_average-6.nii DTI_30_average-6_tensor.nii –fslgrad DTI_30_average-6_bvecs DTI_30_average-6_bvals

7. tensor2metric –fa DTI_30_average-6_fa.mif DTI_30_average-6_tensor.nii

8. tcksample -stat_tck mean DTI_30_average-6_act_sift_0.2M_warpMNI152.tck DTI_30_average-6_fa.mif DTI_30_average-6_act_sift_0.2M_warpMNI152_MeanFA.txt

[jdtournier]

OK, a few things I can help with:

• your data does appear to have the bvecs with the x flipped. Quick fix using some Unix shell magic:

  head -n 1 HARDI150.bvec | awk '{ for (i=1;i<=NF;i++) printf -$i" "; print " " }' > bvec2
  tail -n 2 HARDI150.bvec >> bvec2
  

  Then use the resulting bvec2 file instead of your original HARDI150.bvec.

• I note your DW encoding is not as optimal as it could be. It seems to have been generated assuming unipolar electrostatic repulsion (?), but even then, I wouldn’t expect to find such a small minimum nearest-neighbour angle:

  $ dirstat grad.b 
  grad.b [ 160 volumes ]
  
  ...
  
  b = 2000 [ 150 directions ]
  
    Bipolar electrostatic repulsion model:
      nearest-neighbour angles: mean = 5.70331, range [ 1.16756 - 15.6493 ]
      energy: total = 21534.9, mean = 287.132, range [ 273.419 - 321.434 ]
  
    Unipolar electrostatic repulsion model:
      nearest-neighbour angles: mean = 16.4073, range [ 4.77314 - 17.5676 ]
      energy: total = 10249.2, mean = 136.657, range [ 133.643 - 148.534 ]
  
    Spherical Harmonic fit:
      condition numbers for lmax = 2 -> 14: 1.04062 1.1084 1.21321 1.37722 1.63261 6.27664 24.5671
  

  This compares with the dirgen-produced equivalent:

  $ dirstat dir150.txt 
  dir150.txt [ 150 directions ]
  
    Bipolar electrostatic repulsion model:
      nearest-neighbour angles: mean = 11.9823, range [ 11.3576 - 12.5199 ]
      energy: total = 21028.3, mean = 280.377, range [ 280.171 - 280.928 ]
  
    Unipolar electrostatic repulsion model:
      nearest-neighbour angles: mean = 12.3094, range [ 11.3725 - 20.9024 ]
      energy: total = 10476.6, mean = 139.688, range [ 125.077 - 152.185 ]
  
    Spherical Harmonic fit:
      condition numbers for lmax = 2 -> 14: 1.00096 1.00584 1.01119 1.0252 1.05622 1.11324 1.26462
  

  Not a big deal given that you have so many directions, thankfully.

• the tcknormalise issue arise due to the final warp provided to tcknormalise covering a smaller extent than the tracks, so that the information for those streamline vertices that map outside the warp is incorrect – all these vertices then map to the same invalid location. The simplest fix in such case will typically be to ensure the warp covers the whole brain, or at least the full tractogram. I’m not sure which bit of your pipeline would need to be modified to deal with this, unless your MNI152_T1_1mm.nii.gz is already smaller than the target FoV…?

[SuperClear]

Hi, Donald,

Thanks very much for your assistance! I learned a lot from your analysis of HARDI150 data.

For this post is too huge, I switched my problem to another topic: Image registration for diffusion MRI
Would you help to look into it?

Also, I noticed that the first official MRtrix3 workshop will be held next year. I hope it will be held successfully!
I will struggle for papers. Hope to attend in the future.

Many Thanks and Best wishes!
Chaoqing