[FIX] Amend note about *b*-vecs on DWI specs

[oesteban]

Although this note is true (and the b-vecs should be rotated through the head-motion parameters), it is describing some post-processing step.

The actual implication w.r.t. BIDS of the choice of this format is that, if the scanner generates (or better said, receives and forwards) b-vecs in "world coordinates", then they need to be converted into voxel coordinates before writing into BIDS.

BIDS should describe only how the data & metadata should/could be stored. AFAICT, it should not prescribe how to use them whenever possible.

Comes from mattcieslak#1 (comment)

[mattcieslak]

I've been thinking about this note and you're right the head motion rotations shouldn't be mentioned here. Having curated tons of data in BIDS, the main issue we run into with bvecs is the image axis orientation. For example, oblique acquisitions effectively mandate that a bvec file exists for every scan while plumb acquisitions can inherit bvecs from higher up. Not sure if this is worth noting in the main BIDS spec though

[oesteban]

For example, oblique acquisitions effectively mandate that a bvec file exists for every scan while plumb acquisitions can inherit bvecs from higher up.

What do you mean that "oblique acquisitions effectively mandate that a bvec file exists for every scan"? You mean that the conversion tool has ensured that the bvecs have been converted into voxel coordinates? (and hence make sure the bvec file is generated for every dwi). And then plumb datasets are assumed to be already in voxel coordinates and hence just one is placed at the top level, when a flip of an axis could exist?

Not sure if this is worth noting in the main BIDS spec though

My question above may be put in simpler terms: the problem here is representing the gradients with BIDS or something that conversion tools perhaps should pay more attention to? (or alternative, get #352 merged and do not rely on the conversion tool to do this correctly, as you have been indeed proposing for a long while).

[mattcieslak]

In studies where the scanner operator gets to angle the FoV to capture the participant's brain, each subject gets a unique transform from the requested gradients into image coordinates. So instead of being able to use the inheritance principle the bvecs will be very different for each subject. PIs are often surprised that they can't use one bvec file even though they used the same sampling scheme for every subject because the bvecs need to be transformed for each subject's custom oblique FoV.

dcm2niix and other tools do a great job getting correct bvecs in image coordinates, I was thinking maybe a note would be useful to point this out?

[oesteban]

dcm2niix and other tools do a great job getting correct bvecs in image coordinates, I was thinking maybe a note would be useful to point this out?

I'm totally +1 on this. But I would rather state it within #352, and add ammo to the arguments being discussed. WDYT?

I'd like to keep this one focused on not saying something that is not helpful in the current spec.

[sappelhoff]

BIDS should describe only how the data & metadata should/could be stored. AFAICT, it should not prescribe how to use them whenever possible.

I never worked with this data, but I agree with the general statement and the changes look good.

[effigies]

This seems both reasonable and, to the best of my understanding, correct.