Ordering of BVAL/BVEC in DTI data

[mcraig-ibme]

The ordering of the BVECs produced for DTI data has changed in recent versions of brkraw, and the new code seems to be incorrect at least for some data sets

To Reproduce
Convert DTI data using current PyPi release of brkraw
Repeat conversion using current GitHub code

Expected behavior
BVALS/BVECS should match, or if not the new code should be correct if a bug has been fixed

Actual behaviour

These are the BVECs returned by the current PyPi release for a sample test data set:

0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 -0.046885 -0.038282 -0.394165 -0.321834 -0.022206 0.000000 -0.018131 0.325106 0.265448 0.383046 0.000000 0.312755 -0.026205 -0.021397 -0.459968 0.000000 -0.375562 -0.346362 -0.282803 0.417428 0.000000 0.340828 0.638542 0.521367 0.336037 0.000000 0.274373 -0.407330 -0.332583 -0.664727 -0.542747 -0.638124 -0.521026 0.046062 0.037610 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 
0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.062786 0.051264 0.265265 0.216588 -0.434869 0.000000 -0.355069 -0.159910 -0.130566 0.284917 0.000000 0.232634 0.533527 0.435623 -0.177505 0.000000 -0.144932 -0.545836 -0.445673 -0.483051 0.000000 -0.394409 -0.056164 -0.045858 0.585503 0.000000 0.478061 0.548710 0.448020 0.156614 0.127875 -0.288551 -0.235601 -0.694334 -0.566922 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 
0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.696097 0.568361 0.514743 0.420286 0.548715 0.000000 0.448024 0.599522 0.489508 0.512630 0.000000 0.418561 0.453160 0.370004 0.497608 0.000000 0.406295 0.269792 0.220284 0.288284 0.000000 0.235383 0.282492 0.230654 0.186968 0.000000 0.152659 0.153921 0.125676 0.155890 0.127284 0.015067 0.012302 0.080436 0.065675 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 

These are the BVECs returned by the current Github code for the same data set:

0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 -0.0669317012450247 -0.562695256283439 -0.031700983782903 0.464109134048786 0.546822290075959 -0.0374097058276038 -0.656633398145755 -0.494454132608041 0.595904816615505 0.91155936949506 0.479714334283236 -0.581489536748998 -0.948940403220476 -0.910963518873174 0.0657568055080868 -0.0669317012450247 -0.562695256283439 -0.031700983782903 0.464109134048786 0.546822290075959 -0.0374097058276038 -0.656633398145755 -0.494454132608041 0.595904816615505 0.91155936949506 0.479714334283236 -0.581489536748998 -0.948940403220476 -0.910963518873174 0.0657568055080868
0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0896304521286603 0.378682907197866 -0.620803147253035 -0.228282367494828 0.406737987669393 0.761643801491785 -0.253399920762936 -0.779216184542818 -0.689586269721965 -0.0801779160490655 0.835843064900762 0.783318603395042 0.223576700414847 -0.411925726039013 -0.991206757024889 0.0896304521286603 0.378682907197866 -0.620803147253035 -0.228282367494828 0.406737987669393 0.761643801491785 -0.253399920762936 -0.779216184542818 -0.689586269721965 -0.0801779160490655 0.835843064900762 0.783318603395042 0.223576700414847 -0.411925726039013 -0.991206757024889
0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.993723567909939 0.734828758522887 0.783325283638874 0.855856221793966 0.731812539153803 0.646915167204351 0.710366849308789 0.385145749675837 0.411543711099302 0.403275362083772 0.266909213667293 0.219731391081647 0.222543411871416 0.0215096143488595 0.114826858171662 0.993723567909939 0.734828758522887 0.783325283638874 0.855856221793966 0.731812539153803 0.646915167204351 0.710366849308789 0.385145749675837 0.411543711099302 0.403275362083772 0.266909213667293 0.219731391081647 0.222543411871416 0.0215096143488595 0.114826858171662

The BVEC values in the newer code are scaled relative to the PyPi release which may not be a problem. However they are also in a different order - note that in the Github code all the zero vectors occur at the start of the list whereas in the PyPi code there are fewer at the start and others distributed through the list and at the end.

Comparison with the 4D DTI data shows that the PyPi release is consistent with the data (we see brighter images corresponding to zero BVECs at the exact positions of the zero vectors in the PyPi code, but not for the github code).

The cause seems to be a change to _get_bdata in loader.py flagged as being made on 220201. The data set I previously sent regarding issue #88 can be used to demonstrate the problem.

Please let me know if you need any further information.

[dvm-shlee]

@mcraig-ibme Thank you for creating this issue, and sorry for the long delay on this.

In terms of finding the correct BVEC,
I'm considering using FA colormap to check (red for right-left, blue for dorsal-ventral, and green for anterior-posterior).
could you provide any suggestions if there is a better approach to check this from your data?

[araikes]

I can confirm that the change in _get_bdata is the problem as it is now loading the vector file provided to the system rather than the vectors that are actually "used" by the system. I have reverted the code locally as well as small enhancement per https://dicomifier.readthedocs.io/en/latest/diffusion/bruker/index.html though I would note that in my data I almost need a permutation and flip of the bvecs.

I would suggest, personally, a visual assessment using color FA maps as well as a sanity check using MRtrix's dwigradcheck (which is what I do).

EDIT: Regarding the flip/permutation, I think this is a difference between XYZ orientation in the bvecs as I'm writing them and the orientation of the NIFTI (RPS?)