ADC with Mrtrix 3.0

1

Hi MRtrixler,

I was playing arround with your list of tools and tried dwi2adc.

“convert mean dwi (trace-weighted) images to mean adc maps”

  1. Do I really use the Trace? And how do I calculate it with MRTrix 3. Didnt found it.
  2. I used the normal DWI data and with B1000 it looks fine to me. But with B2000 and B3000 its too low for CSF, GM, WM and so on…
    3.There are two datasets in ADC File. The second one is the ADC. What is the first one?

Thanks and greetings to you all,

Ralf

2

The documentation is indeed a bit lacking in this command… I added it quite a while back to help out a collaborator, but the reality is very few users will ever need it. In short, dwi2adc is only to be used with very specific data that were acquired using a trace-weighted MRI sequence. It is not appropriate for ‘regular’ DWI or HARDI data. So it’s no surprise that the output of that command applied to ‘normal’ DWI data would look a bit odd - I’m actually surprised you say it looks fine at b=1000 (although I’ve never tried myself)…

This also means there is no need to ‘calculate’ the trace-weighted image (even though you probably could), since you can already use the normal dwi2tensor + tensor2metric route to calculate all the maps you need.

The two volumes in the output correspond to the estimated b=0 image and ADC map respectively.

1 Like
3

Thanks for the quick answer,

its funny I calculated the the same data with the dwi2tensor way and its nearly the same.
That means I am not convinced with the B3000 ADC values. They are too low.
The CSF is always under 0.0017 (mm²/s). Thats too low.
Can be a 7T problem. But I am not sure about that.
It takes the B=3000 from the header? Doesnt it?
So external enconding.b file wouldnt do a thing.

Ralf

4

I’m not entirely surprised about that, since on average, the value would be close to what you’d expect in the trace-weighted image anyway. Maybe that’s why it’s close.

This does sound odd. The CSF would be isotropic anyway, so there’d be very little difference between the trace-weighted and regular directional DW signal in those regions. Maybe noise can play a part in this? The fit is a regular log-linear least-squares fit in this command, as opposed to the iteratively reweighted least-squares fit performed in dwi2tensor - that might explain the difference, assuming it’s not too large.

Yes, it does take the encoding from the header if present. But if you supply your own encoding.b file, it would ignore the header and use what you’ve explicitly supplied - this is a design decision we made: the command should do what was asked of it…

5

@jdtournier , @Ralf Wouldn’t it just be the noise floor? Or you reckon the difference is too drastic for that to be the sole reason? I actually remember seeing (CSF) ADC values in this range as well on some of our data (just coming through the dwi2tensor and tensor2metric combo; also large b-values, e.g. 3000).

6

I calculated it with FSL and its also too low. For the noise…I would say…its to much of a difference and I took the 1.4 mm iso data. The noise starts a bit at 1.2 or more at 1.0 or 0.8. mm iso !
How is the calculation done? I measured the subjects with 1000, 2000 and 3000. And the ADC is going down linear. I mean 1.4 mm iso and B=3000 is near the end of good data, but it is still good. I testet also 1.0 iso data with b=1000 and 2 averages and the ADC is fine. The noise at that data should be or is worse than the noise at 1.4 iso with b=3000.

7

Hi again,

is there a way to calculate the ADC with MRTrix using more then 2 B-Values? That would be the propper way for the fitting.
Would be intressting to see what happens with 4 values.
I guess the problem ist the SNR and the fitting. If you have only b0 and b3000 for the calculation…

If MRTrix is not able to, do somebody know if FSL is able? Or I have to use Matlab or ImageJ or something…

THX,

Ralf

8

I’m not sure I’m following everything you’ve said, but in any case: dwi2tensor will use all the b-values in the data, as specified in the DW scheme. You actually have to go out of your way to perform a single-shell DTI fit from a multi-shell acquisition. I assume you’ve been using something like:

dwiextract dwi.nii.gz -fslgrad bvec bvals -shell 0,3000 dwi_b3000.mif
dwi2tensor dwi_3000.mif dt.mif
tensor2metric dt.nii -adc adc.mif

to get these ADC maps, right? Or as a one-liner:

dwiextract dwi.nii.gz -fslgrad bvec bvals -shell 0,3000 - | dwi2tensor - - | tensor2metric - -adc adc.mif

Can I just check one thing though: when you extract one of the shells, you do include the b=0 volumes too, right? If that first step was only:

dwiextract dwi.nii.gz -fslgrad bvec bvals -shell 3000 dwi_b3000.mif

you’d end up with just the b=3000 shell volumes, no b=0. It wouldn’t be surprising then if the fit was pretty bad…

9

Sadly not. I have three different datasets for the shells…all with the B0s inside.
But if I understand correctly, I can but them into one file and will get the right ADC for the Multishell, right?
So I have more data points for the ADC value and is…maybe more right.
Is then the lograithmic calculation?

Is there a dwimerge? Got it: mrcat dwi1 dwi2 dwi3!

It worked on that way. The Multishell is a bit too low, but not to much. Its close and the CSF looks fine.

Question: Why do I have only one dataset in the Multishell result. And the two datasets in the result of the single shells?

10

I thought the HCP data came as one file with all the shells together? Maybe someone split the data up before you got hold of it…?

Well, it’ll be different. But bear in mind that ADC calculations are never ‘right’ - that’s why it’s called the apparent diffusion coefficient. It’ll be affected by acquisition parameters (notably b-value, diffusion time, SNR), and post-processing methods (non-linear / log-linear / weighted log-linear fitting - ignoring motion & eddy-current distortions and outlier rejection).

And while it should be OK in CSF since that can be assumed to be more or less free diffusion, the problem is there’s no signal to speak of beyond b=1000 s/mm², so it’s not surprising that most tensor fitting approaches will give something unreliable - you’re essentially fitting the ADC to the ratio of the rectified noise floor to b=0 signal (i.e. ln(σ/S0) = -bD)…

Sorry, not sure what you’re asking…

:thumbsup:

One of the issues with tensor fitting on multishell data is that the tensor model is actually a poor fit - the signal decay as a function of b-value is not mono-exponential, that’s the whole basis of diffusion kurtosis imaging. So you’ll get different answers depending on what b-values you include in the fit - as you’ve found. For the CSF, the issue is that the higher shells will be essentially pure noise, and that’s very difficult to deal with in a way that doesn’t negatively influence the fit - the best case scenario is that the fitting procedure identifies these values as noise and ignores them. The weighted least-squares strategy in MRtrix3 will heavily down-weight the higher shells, but won’t completely ignore them. The only way to really deal with it is to use a non-linear Rician-bias corrected fit, but in my experience this is very unstable in CSF regions, and heavily reliant on having a solid estimate of the noise level, which is not trivial.

So in short, I wouldn’t get overly worried about trying to get the ‘right’ values for the tensor fit, I don’t think there is such a thing (particularly in parenchyma where the assumption of free diffusion is clearly invalid). What’s probably more important in practice is ensuring that whatever strategy you do use is reproducible - and that means acquiring strictly equivalent data and using the exact same processing pipeline for all the data included in your study.

I think you’re asking ‘why do I get a single ADC volume using the regular tensor fit, and two volumes in the output for the trace-weighted fit (as performed by dwi2adc)’ - is that right? If so, that’s nothing to do with whether it’s multi-shell or not: the ADC is computed across all shells. tensor2metric outputs exactly what you asked, and you get the ADC map with the -adc option.

As I mentioned before, dwi2adc is a very niche application that I don’t expect most users will ever need. I haven’t put the same amount of effort into making the interface as user-friendly or well-documented (although I may have to do that, given this discussion). So it produces both the b=0 and ADC values as separate volumes in the same image, because that’s the information that was needed at the time…

If you also want that b=0 option with a regular tensor fit, there is now a -b0 option in dwi2tensor to do precisely this.

11

Thank you Donald,

sometimes little tests can bring you to a mountain of questiona. But I understand much more about MRTrix now.

3 Single dataset shells: its not HCP data it was my own data. I measured it myself and allways put the shells in Single Sessions, because the measure time is very long (especially for 1mm or .8mm) for one session. And its good to give the subject a break and talk to them.

Sorry about the question with two datasets in the results. I mixed it with the dwi2adc results and was wondering.
The logaritmic questions was just for the curve fitting with the old manual calculation of the ADC with 6 or 7 B values.
I thought it was logaritmic there.

If I have free time, I like to play a little around with DWI data. Often not enough time to go deeper into the matter.

Thanks,
Ralf

12

4 posts were split to a new topic: Gradient table for dwi2adc command