Clarify existing aspects of the BIDS diffusion specifcation

[neurolabusc]

Since the BEP brings together a lot of diffusion domain-specific expertise, I suggest the team can develop a consensus on the (potentially ambiguous) existing diffusion details of the BIDS specification. Here are a couple areas I think should be considered for amendment:

1. bvec definition needs to mention that the bvec file is in FSL format. This format is not only in image space, but it assumes the sform/qsform has a negative determinant. If the spatial transform has a positive determinant, the polarity of the first row must be inverted. This is because FSL diffusion tools will reflect image column order to ensure a negative determinant. This unintuitive feature is described here and has caused confusion and grief. I actually like the mrtrix documentation on this topic. For full disclosure, this complexity led me to argued against using this format when the BIDS was first drafted. However, this was the consensus choice, and it has now been widely adopted, so I think we should at least explicitly describe the chosen format.
2. For the above reason, I would personally not allow bvec files to qualify for the inheritance principle. For Siemens (and I think many other vendors) gradient directions are specified in world space, so the same sequence will generate different FSL/BIDS image space bvecs when the angulation changes. At the minimum, I think the specification of the inheritance principle should explicitly warn users Ithat bvecs are typically specific to the particular image that it corresponds to.
3. I think it is worth the BEP016 group discussing the fate of the derived diffusion measures (TRACE, ADC, MD, FA, etc) often generated automatically by sequences. As @Remi-Gau noted, if the image was generated by the scanner, the typical BIDS philosophy is that it is raw rather than derived. For example, scanners can generate MoCo, nonlineargradientcorrection, and indeed virtually all our images are in some sense derived from k-space and multiple coils. I do think it might be good to provide guidance for users on the scanner derived diffusion data. My own sense is that the derived diffusion measures (TRACE, FA, etc) created by the scanner are typically inferior to the same measures created after the raw directional diffusion data is offline processed (denoise, deGibbs, eddy, TOPUP). I would advocate that the specification explicitly notes that scanner-generated derived diffusion measures should be either discarded or treated as derived.

[Lestropie]

1. To my knowledge this was first flagged in Incomplete description of DWI bvecs format bids-specification#243. But I suspect that it's one of those cases where nobody wants to take responsibility for writing the relevant documentation. I might have to bite the bullet myself at some point.

2. Mmmmm, that's a good point. I would support that argument, though there's going to be resistance from a backwards compatibility perspective.
   I could imagine that in an ideal scenario, the validator could identify all files to which a particular bvec file is applicable, and ensure that all possess identical cosines. But I've yet to convince the powers that be of even preserving rather than discarding entirely the inheritance principle, let alone having such context-specific inheritance-principle-related plugins attached to the validator...

3. This is probably another case where I'm slightly hesitant because the scope of the issue is well and truly beyond that of DWI, and I would not pretend to dictate to the community how this conflict should be dealt with. Are there links to any existing discussions regarding classification of acquisition-hardware-delivered "derivatives"? Not something I've committed a great deal of thought to. I know that it's impermissible to name a derivative file anything that could pass as a raw file, so I suppose that in a round-about way, if you were to permit storing such data in your raw dataset, that would then preclude you from representing such in a derived dataset?!?! The derivatives file naming conventions section of the specification is currently not entirely precise in this regard.
   I agree with the idea of treating such scanner-generated derivatives as derived data. But I think such an instruction would still leave many researchers confused. I can envisage an example DICOM to BIDS conversion where incoming DICOM series are explicitly separated between raw and derivative directories by the specified converter template, with the latter being the result of a "pipeline" that was executed by the scanner, and is stored in a format consistent with BEP016. That structure would then be faithful to comparison of such images against what comes out of a more complex image pre-processing pipeline.

[Lestropie]

RE 2, should link to #1293; issue is a little more fleshed out there already.

[PeerHerholz]

Also adding @arokem, @oesteban and @francopestilli to this discussion.

[oesteban]

Re 1: This may not resolve the problem entirely, but it was the idea - bids-standard/bids-specification#352. Please have a look.
Re 2: I'd be fine with explicitly excluding bvec/bvals from the inheritance principle.
Re 3: I think it should be addressed separately, and IMHO BIDS-"raw" should specify how to store them, without necessarily BIDS-Derivatives implementing the same solution.

EDIT: fixed the link to bids-standard/bids-specification#352.

[Lestropie]

RE 1:
- bids-standard/bids-specification#352 would facilitate inheritance specifically for the case of data where a dMRI sequence executes the diffusion sensitisation with respect to the physical scanner axes (and hasn't been rotated by pre-processing). I don't know if such currently exists, but it's hypothetically possible for a sequence to execute those gradients with respect to the image axes, in which case TSV gradient info in RAS could not use inheritance whereas TSV in IJK / bvecs hypothetically could.
- Over and above bids-standard/bids-specification#243, bids-standard/bids-specification#352 would need to provide additional clarification on the fact that IJK rows in a TSV and columns in a .bvecs are not equivalent.
- Can collectively consider making an argument as to how such things could change in BIDS 2.0 if what we think is the right solution would break backward compatibility.