And, as one more note on this topic, a comment about 3dDWItoDT:
The b-matrix, which is essentially what is used in the tensor calculations, is given by:
b =
b g gT,
where
b is the DW magnitude (what we call b-value, a scalar) and
g is the DW gradient (a 3-component vector, which usually has unit-magnitude); the operation of the gradients here is an outer product, producing the 3x3 b-matrix.
If one were going to estimate
b just from a single input gradient, then one would have to have the b-value information included in that gradient using an appropriate scale. From the equation above, the most appropriate scale would be the square root of the b-value, so that one could define the new input quantity as
h = sqrt(
b)
g, with the result that:
b =
h hT = [sqrt(
b)
g] [sqrt(
b)
g]
T = sqrt(
b)*sqrt(
b)
g gT =
b g gT.
All this is fine and well, and if one entered something like
h into 3dDWItoDT, everything would be fine. *However*, most programs don't output gradient values scaled by the
square root of the b-value, they output a gradient scaled by the
full b-value: that is, they make some
k =
b g. This would create a problem in the above equation, where the calculated b-matrix would be:
b' =
k kT =
b2 g gT,
which would be wrong (except in the special case that the b-value was 1). If a gradient scaled as in
k is input, then the *correct* b-matrix would be:
b = (
k kT) / |
k| = (
b2 g gT) /
b =
b g gT.
Therefore, instead of changing the input format of the gradients to be scaled by a square root of the b-value, 3dDWItoDT will assume that the gradient is scaled by the full b-value, and adjust internally to produce the correct b-matrix (using the last equation). 3dDWUncert will also assume this, and so will 1dDW_Grad_o_Mat for making its b-weighted inputs/outputs.
