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…

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.