Hi everyone,

So, I have a DKI dataset with 30 directions (for each of the b-values) and 2 b-values (the directions are identical for both of the b-values). I have used DKE to extract the maps. The b=0 threshold has been set to 0 (I tested this with 50 and 100 as well), "DWI Spatial Smoothing", "co-register scans" and "interpolate" unchecked and Median Filtering set to No filtering. The maps I get are very noisy and it takes almost 7 hours for DKE to process the data and spit out the maps. I have attached an screenshot of one of the FA maps for your reference. Could anyone help me figure out where the problem lies.

Thanks a lot in advance,
Ehsan

Hi Ehsan,

DKE should definitely not take 7 hours to run. Masking in some way can reduce this time significantly since so much of the image is background, where the fitting algorithms won't work well and may run extra slow. DKE uses a simple connected components analysis for masking, but if this doesn't work for you, you can use the brain extraction tool from fsl, which can be manually applied to your images before running DKE.

However, your FA image does look fairly noisy within the brain volume. What voxel dimensions and b-values are you using? If everything is set up and it is still taking a long time to run, my guess is that your highest b-value images may have a very low SNR. Have you looked at these? If the SNR drops, DKE's fitting algorithms also might run slowly and the parameter estimates can even become biased.

First things to check are resolution, b-values, head coil, coil combine mode (something like adaptive combined opposed to sum of squares!), parallel imaging acceleration factors, etc. 

Spatial smoothing can also help with some of this. We typically recommend a Gaussian smoothing kernel of 1.25*voxel dimensions. However, there are a myriad of different ways to incorporate noise correction and artifact removal (such as Gibbs ringing) into DKE fitting routines. These can all affect the quality of the parameter estimates.

Best,

Russell

Hi Russell,

Thanks a lot for your response. I ran DKE with another b=0 threshold. It didn't take as long, though it still took longer than what I expected (I am expecting less than 20 mins!) and the images don't look as noisy. The problem is that the maps still have the skull and scalp. I tried using ExploreDTI and it took about 78 seconds to convert the NIfTI file to a .mat file readable by ExploreDTI and about 1 min to extract the FA map. I suspect the same thing applies to the other maps using this program. So, my two questions are:
1. Why do you think the two software packages are this much different in terms of the processing time?
2. What is your recommendation for the b=0 threshold so that the scalp and skull get masked out? I don't have problems with using FSL's BET, but honestly, I don't feel good about adding another program into the pipeline!

Thanks,
Ehsan

P.S: Our b-values are 0, 998 and 2994 and the resolution is 1*1*2.

Hi Ehsan,

20 mins is very reasonable. The DKE scripts are 'parallelized' using MATLAB parallel computing toolbox, so it will run faster if you run it on a CPU with more cores or over a cluster... maybe one day we'll have a GPU implementation, but right now the optimization script won't work down there...

1. DTI fitting is super easy. You just have to solve x = (H'*W*H)^-1*H'*W*y; which is purely linear number crunching, which computers are great at and it's easy to run through an entire image volume in less than 1 min, even in Matlab. The basic linear estimation problem is the same in DKI but we utilize higher order signal model with higher order terms in the b-value and more unknowns. Consequently, the pure linear fit is often noisier than desired. There's a whole host of literature on DKI fitting (including a bunch of non-linear techniques and Gibbs ringing removal in the preprocessing where the linear estimation is better). Our algorithms use a constrained linear least squares which just applies some physical constraints on the solution to the linear technique. This requires more computational time, and when the images are noisier it takes even longer. This is what I suspect may be contributing to your image processing times. On top of that, DKI's source code is written in Matlab, which is inherently slow. I don't know what ExploreDTI is written in by C-based languages, for example are typically much faster.

2. FSL's BET is an excellent masking tool. DKE just applies a simple connected components analysis which is not as robust as BET's approach. If you're comfortable utilizing this, then I would recommend it :) You can mask the DKI images prior to running DKE. I've often used semi-automated approaches. The masking doesn't affect the data though, so if you're analyzing stuff inside the brain, you can always just ignore the skull stuff...

Hope that helps,

Russell

Hi Russell,

Just so you know, I tried feeding in the same image with the same parameters once without doing BET and once after brain extraction. It took about 40 mins to process the extracted version and about one and a half hour to process the original image. I think 40 mins is also what you would expect to be reasonable, is that right?

Also, I'm trying to find out which of DSI Studio and TrackVis to use for tract extraction. The fact that TrackVis has 3D ROIs is tempting, but there is a major limitation in TrackVis and that is that it cannot show the glyphs, which I would assume to be a great way to know if one has extracted the right tract or the processing steps have gone the right way. What would be your suggestion on this?

Thanks again,
Ehsan

Hi Ehsan,

40 minutes is reasonable though this will depend on the size of your data set and computational platform. I do hope we can continue to improve the processing times in the future.

I would definitely recommend DSI Studio as a more versatile tool for analyzing your data; however, TrackVis is not with out merit. For example, they do have different ROI tools, and TrackVis can be very useful in visualizing the data and selecting certain subsets, etc.

DSI Studio does have ROI options too, and I haven't explored them to their full extent but they can also be loaded in, or manually drawn to select certain tracts, so there are a lot of options. I find that visually assessing the ODF glyphs and orientation estimates is crucial for making sure everything is lined up. I've attached an example from a clinical study with 30 gradient directions as a reference. You can also do things in DSI Studio like overlaying a t1 image which is also useful / cool for visualization. Hopefully in the future we can also provide more analysis tools :)

One last point about the two software platforms. I thought that we had corrected all orientation issues in making the .trk files compatible with both, however, much to my chagrin sometimes they will overlay correctly in one but not the other. I am biased towards working in DSI studio and if you load an image in there or use their pre-processing scripts, they put the image and gradient table in LPS, so in making the .fib file, I did the same. However, this may cause the tracts processed with DKE or DSI Studio to not overlay with an image correctly in TrackVis. This can be overcome by changing the ImageOrientationPatient field in the .trk header but I wish there was a better solution :/

In future versions we will also output a vox_to_ras transformation which will help with programs that expect the tracts to be in MNI space...

Best,

Russell

Awesome. I'll try DSI Studio and will get back to you with my feedback!

Thanks,
Ehsan

Hi,

I still have the same problem. Due to the low SNR, we re-scanned  a test patient using the philips dki protocol provided by the experienced users and yet I have this noise problem.

I tried to run the software with different b=0 value, filtering, noise tolerance value??

Any more recommendation?

Thanks in advance

Hi Sevim Sahin, 

Can you walk me through your way of processing the DKI images (e.g. do you use .dcm or .nii / GUI or .exe / what are your settings). 
The screenshot you attached looks indeed very noisy, although I have a suspicion your gradient directions might not be matched accurately with your images resulting in some very poor fitting. 

Could you attach your DKEParameters file as well? 

Best, 
Emilie