Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Output of utils.density_map() using tck file is different than MRTrix #2170

Closed
davidrs06 opened this issue May 18, 2020 · 2 comments
Closed

Comments

@davidrs06
Copy link

Description

I generated a tractogram using MRTrix, and saved it in tck format. I also generated a tract density image using MRTrix's tckmap -template DWI.nii.gz tractogram.tck tdi.nii.gz where DWI.nii.gz is the input diffusion volume.

Issue

When I load the tractogram using nibabel and compute the tdi image using dipy, I get a map that has quite less fiber count per voxel (between a few to more than 200 for some regions, with a mean around 50 streamlines less). Is this expected ? I imagine MRTrix and Dipy might compute differently how voxels are "visited" or not by the streamlines, but I wondered if someone knew about another explanation, and which map is more accurate ?

Code

Here is the code I use to compute the map using dipy:

import nibabel as nib
from dipy.tracking import utils

DWI_img = nib.load('DWI.nii.gz')
tractogram = nib.streamlines.load('tractogram.tck')
tdi = utils.density_map(tractogram.streamlines,DWI_img.affine,DWI_img.shape[:3])
nib.save(nib.Nifti1Image(tdi,DWI_img.affine),'/tmp/tdi_dipy.nii.gz')

I'm using dipy v1.0.0, python 3.7.4 on a mac (Darwin-17.5.0-x86_64-i386-64bit)

Thanks in advance for any feedback !

Cheers,
David

@Garyfallidis
Copy link
Contributor

Hi David (@davidrs06) ! As far as I know the method implemented in DIPY was not made to replicate the behavior of the mrtrix command. The algorithms used are possibly different. I think you should look inside the code to understand how things are calculated. There is another function that you could look into called track_counts. @jchoude has contributed an extension of this command that also accounts for the case were the streamlines may have points with variable step size.

@davidrs06
Copy link
Author

Hi Ele :). Indeed, it's not so much of an issue, I was more wondering if the difference was intended or not. Thanks for the answer, I'll have a look at the code.
Take care !
David

@skoudoro skoudoro added this to the 1.2 milestone May 19, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants