Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
tsalo opened this issue May 13, 2024 · 11 comments
Open

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

tsalo opened this issue May 13, 2024 · 11 comments
Labels
DWI Issues related to diffusion-weighted imaging (DWI) extensions Changes to supported file extensions.

Comments

@tsalo
Copy link
Member

tsalo commented May 13, 2024

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.

@tsalo tsalo added extensions Changes to supported file extensions. DWI Issues related to diffusion-weighted imaging (DWI) labels May 13, 2024
@poldrack
Copy link

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
Copy link

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
Copy link

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
Copy link

mattcieslak commented May 13, 2024

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
Copy link

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
Copy link

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

@yarikoptic
Copy link
Contributor

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

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
Copy link
Member Author

tsalo commented May 15, 2024

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
Copy link
Contributor

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
Copy link

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
Copy link

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
DWI Issues related to diffusion-weighted imaging (DWI) extensions Changes to supported file extensions.
Projects
Status: No status
Development

No branches or pull requests

6 participants