Replace DWI FSL-format bval/bvec files with MRtrix-format tsv file

[tsalo]

This stems from bids-standard/bids-specification#349, which proposed supporting the MRtrix-format tsv file as an optional alternative to FSL-format bval and bvec files. For BIDS 2.0, I propose a fully backwards-incompatible replacement of the FSL-format files with the MRtrix-format file.

Pinging @mattcieslak, who originally proposed supporting the MRtrix-format file.

[poldrack]

Given the prevalence of bval/bvec files (which I agree are not optimal), I think we would need a very strong justification for making such a breaking change. (whereas making it an optional format alongside bval/bvec seems like a no-brainer)

[mattcieslak]

I'm ok with keeping a bval and bvec file alongside a reliable description of the gradients! Even though the bvec files are so common, they're not actually useful on their own. Even the bids standard is ambiguous about this. It describes DIPY bvecs, not FSL

[poldrack]

can you please define "useful"? There are certainly some things that one can do with a simple set of bvec/bval files; I'd like to have a better feel for what the threshold for utility is, given that such a change would make the majority of current datasets with DWI incompatible in a way that that is likely impossible to fix without the original DICOMs (at least I think that's true).

[mattcieslak]

Sure - if you have a _dwi.nii.gz and a bval and bvec from dcm2niix, then you have some certainty that the image is in LAS+ and the bvecs are indeed aligned to the image axes. You can fit models directly in DIPY or in FSL with these bvals and bvecs and be fairly certain that your gradient directions are correct.

If you're operating anywhere outside of those inputs then you have to run some sort of bvec checker to see if the directions are aligned with the image axes (DIPY convention) or the image-axes-if-the-image-were-in-LAS+ (FSL convention). Some examples of these situations are when the images come from animal scans or when the images are created via simulation in FiberFox (and use LPS+ image axes and bvecs in the DIPY convention).

So in a nutshell, the bvecs are good to go as long as your corresponding image is in LAS+ orientation. If not then you need to run dwigradcheck, or DSI Studio's bvec checker or some equivalent tool to permute the bvecs and flip their signs until you're able to produce some coherent tractography.

[poldrack]

Thanks! I will be interested to hear from others, but I don't find that to be a compelling enough rationale to make a breaking change that renders existing compatible bval/bvec files incompatible with the next version of the standard.

There is also a more general point to be discussed here (probably in a different issue): How should the community balance aspirations for better methodology versus breaking compatibility with existing datasets? Is there a middle ground, or should BIDS 2.0 (or maybe 3.0) be envisioned without regard to backwards compatibility? Perhaps this discussion has already been had elsewhere, in which case please pardon the noise!

[mattcieslak]

It may just boil down to the community's tolerance for vestigial files

[yarikoptic]

How should the community balance aspirations for better methodology versus breaking compatibility with existing datasets?

I think for this particular aspect, "datasets compatibility" (as opposed to tools compatibility), having a migration tool would largely address this concern. That is why in WiP

• BIDS-2.0 bids-specification#1775

I started with having such one in mind and coded it up for participants -> subjects as an example: https://github.com/bids-standard/bids-specification/pull/1775/files#diff-b81290f4f0476f7197f66bf34cab9f750df9401d7aaa05caf78732e542c97181R43

Is there a middle ground, or should BIDS 2.0 (or maybe 3.0) be envisioned without regard to backwards compatibility?

BIDS 2.0 "by definition" could be breaking backwards compatibility but IMHO it shouldn't be a "wild game" - any breakage (for dataset or tool compatibility) should be warranted.

As for this particular issue I lack DWI expertise, so will leave decision making to others involved. But for now I added it to "BIDS 2.0" project as a viable candidate we decide on either to tackle for 2.0, close, or postpone to 3.0.

[tsalo]

What about deprecating the FSL format files in BIDS 1 first? Would that make dropping support for them in BIDS 2 more palatable?

Or deprecate through 2 and remove in 3 even, if 2 will happen soon.

[yarikoptic]

In principle we could indeed start RECOMMENDing the replacement format in BIDS 1.0, thus in effect "deprecating" in the left over of 1.x, and add migration for BIDS 2.0 completely removing FSL format.
As we do not have specific timeline for 2.0, I would not dare to recommend waiting for 3.0 if we want to see some "movement" on this.

[Lestropie]

There are still outstanding issues with various DWI softwares not appropriately handling bvec/bval files. I am trying to improve definition of that format in bids-standard/bids-specification#1811. Also, as part of BEP016 and some MRtrix3 work, I'm hoping to produce a software tool that verifies appropriate software handling of gradient tables and other data relevant to orientation dependence (ie. beyond the scope of dwigradcheck); I'll try to remember to report progress back here.

Given the ubiquity of dcm2niix in this ecosystem, I think that a change like this would be ill received were there not to be a corresponding change to dcm2niix giving it the ability to produce gradient table data in that format (which can then be trivially renamed to become BIDS compliant). @neurolabusc is this a change that you'd be willing to implement upstream?

[neurolabusc]

@Lestropie first of all, I think you did a masterful job with your extended description of the bvec format, as this finally describes the unintuitive nature of this format. I would be happy to try to integrate software you develop. dcm2niix is written in vanilla C, with minimal dependencies so that would be my preferred language.