dwiextract -shell produces slightly distorted b-values and b-vectors

[ansk]

Dear experts,

I have noticed that dwiextract -shell slightly distorts b-values and b-vectors.

My mrtrix version: 0.3.15-457-g80f4abf0

Example:

mrinfo -property dw_scheme example.mif.gz

(part of output):

-0.5629470545,-0.550515324,0.6164610616,2500
0.2583717165,-0.1301881376,0.9572334507,2500
-0.7518837812,0.6402583973,-0.1572920504,2500
-0.3277215687,0.8722226455,0.3630795368,2500
0,0,0,0

dwiextract -shell 0,2500 example.mif.gz example_2500.mif.gz

mrinfo -property dw_scheme example_2500.mif.gz

(part of output)

-0.5629468438,-0.5505151179,0.6164608309,2500.001871
0.2583716165,-0.1301880872,0.9572330802,2500.001935
-0.7518834711,0.6402581332,-0.1572919855,2500.002062
-0.3277214835,0.8722224187,0.3630794424,2500.0013
0,0,0,0

The difference is probably cosmetical, but maybe it deserves fix anyway.

[dchristiaens]

The difference is purely numerical, introduced due to consecutive string-to-float and float-to-string conversions (loading the gradient table in memory and later writing the selected gradients to the output file). We could fix this by directly copying the text from the input file header to the output file header, but it's probably not worth the effort...

[jdtournier]

The difference is purely numerical, introduced due to consecutive string-to-float and float-to-string conversions (loading the gradient table in memory and later writing the selected gradients to the output file).

Just to clarify: the numerical differences arise purely because of the scaling of b-values by the vector norm (to allow correct processing of multi-shell data sets, on many systems that's the only way to acquire them in the first place - this is discussed in multiple places here, see .e.g #48). The numerical differences here are simply because the norm of the vectors isn't exactly unity. It can safely be ignored.

We could fix this by directly copying the text from the input file header to the output file header, but it's probably not worth the effort...

We already do in general - as of 924c767, as part of #48... These modifications only apply at the point of use now. The difference here is that dwiextract needs to apply these modifications to ensure it's getting the correct shell. What we could do in this particular instance is extract the information from the original unmodified DW scheme, as you suggest. I agree I'm not sure it's worthwhile, but it should be relatively trivial (I think...?) if it proves important.

[ansk]

Thank you for the clarification. It is reassuring that this is not really an issue. On the other hand, for the uninformed user this behavior could raise some suspicion. Therefore, in case it does not take much effort I would vote for the fix.