-
Notifications
You must be signed in to change notification settings - Fork 160
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
[ENH] Optional alternative to bval/bvec #349
Comments
Looking at the format, I think this in TSV would be a reasonable type of data to support. Our TSV files always have column headers, which will help make it more explicit that these are RASB columns. So it would be roughly:
We definitely need to continue to allow bval/bvec, since that's part of the standard, but I would personally be fine with permitting a more generic format that is more consistent with BIDS. Given that it's Tagging @bids-standard/raw-mri-dwi. |
I think FSL supports the 3xN bvec format, but it has not been widely promoted. |
@effigies that sounds great! It's also worth noting that world coordinate are typically available in dicoms headers, so going directly from dicom header to tsv removes a potentially incorrect transformation to image axis coordinates. @cookpa do you know what coordinate system the 3xN bvec format uses? |
It's the same as the Nx3 format, ie radiological voxels
https://fsl.fmrib.ox.ac.uk/fsl/fslwiki/FDT/FAQ#What_conventions_do_the_bvecs_use.3F It's just a bit more readable to have x y z rather than the transpose. |
LOL. Nobody's actually in that group but me... I guess I'll abuse the teams a little and tag @bids-standard/derivatives-mri-dwi. If any of you (including @mattcieslak and @cookpa) know anybody else who should be in this discussion, tag them in. |
Maybe @Lestropie, @Garyfallidis too? |
… On Sat, Oct 19, 2019, 08:04 Matt Cieslak ***@***.***> wrote:
Maybe @Lestropie <https://github.com/Lestropie>, @Garyfallidis
<https://github.com/Garyfallidis> too?
—
You are receiving this because you are on a team that was mentioned.
Reply to this email directly, view it on GitHub
<#349?email_source=notifications&email_token=AAESDRVOHXFIWAYCTI6BQ4TQPMOYVA5CNFSM4JCIMVXKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBXSY4I#issuecomment-544156785>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAESDRSFOTYWGAVW7KG2VG3QPMOYVANCNFSM4JCIMVXA>
.
|
I ignore whether this is under discussion, but if the bval/bvec convention is to be re-visited, it may be worthwhile and the occasion to include other encoding methods (i.e. b-tensor encoding), and to consider how these can make into the specification. |
@jhlegarreta that is a good idea. I know software exists for reconstructing GTI scans, but is there a file format for b-tensors yet? |
@mattcieslak not that I know. I'd dare to say that labs that use such encodings have implemented their own solutions to deal with the data. Also, neuroimaging toolkits may have started or have already started to think about incorporating the ability to read such data into their pipelines. IMHO BIDS is the venue where these efforts should be put in common to gather consensus and define the format. |
@jhlegarreta, storing b-tensor encoding would be possible with a 7-column tsv file? If so, I think the reinterpretation of mrtrix's format by @effigies here (#349 (comment)) would generalize well to b-tensor encoding, we just need to define the right column names. |
In the sense of dealing with raw vectors, I would also support the idea of a single tsv containing the b values and x, y, z in RAS+ per the suggestion from @mattcieslak. In a derivatives sense (i.e. esp. within the DiPy universe), I’ve found it helpful to further save the gradient table object as pickle (where the suffix could even formally be called .gtab) since passing gtab object itself doesn’t play nice with workflows. In other words, vector metadata really needs its own format, too (e.g. so that B0 indices are not lost, and so that we can store tau, deltas, qvals, etc.). It would be nice though if this could generalize beyond python, perhaps finding a way to house vector metadata cleanly in .json? (Relatedly, a json read/write method for the gradient table class in DiPy could help with this) |
my 2ct: Pickle is just a serialization of data specific to Python. I believe dipy or any other software could have simple readers that build the desired object directly from the tsv file. In addition, pickle is not human readable. Not sure it is really helpful in derivatives either. |
+1 to the general idea. I also like the idea of a tsv file for this. A json sidecar could potentially be used to discriminate between b-matrix and b-vector representations. I agree that reading and writing these (e.g., in DIPY) should be straightforward to implement. The json sidecar could also be used to specify the units of the b-values (which could vary in their order of magnitude). |
(thanks Oscar)
+1 for me too, I like the tsv + json idea as well. Tsv with column names to
avoid confusion and the json file with the extra required information.
Just thinking aloud, not sure if this makes sense but happy to hear
opinions:
- could the json have information related to the diffusion file as well? I
mean, for example, {LAS/RAS, [-1,2,3,4]/[1,2,3,4],
neurological/radiological} information that could be used to check the b
values against the file for extra security
- and maybe history of manipulations of the b-values?
For example, files generated by dmriprep will be the input to other
different analysis tools. Once you start with the analysis pipeline is
always good to know what happened to your origin files (rotated by ...,
flipped x by ..., etc. )
…On Sat, Oct 19, 2019 at 3:20 PM Ariel Rokem ***@***.***> wrote:
+1 to the general idea. I also like the idea of a tsv file for this. A
json sidecar could potentially be used to discriminate between b-matrix and
b-vector representations. I agree that reading and writing these (e.g., in
DIPY) should be straightforward to implement. The json sidecar could also
be used to specify the units of the b-values (which could vary in their
order of magnitude).
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#349?email_source=notifications&email_token=ABCZAVYMJ4UVRHSHARC4RCTQPOB4HA5CNFSM4JCIMVXKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBX52BY#issuecomment-544201991>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABCZAVY4JA3RGJV7Z6G57SLQPOB4HANCNFSM4JCIMVXA>
.
|
Are we sure there's a need for neurological/radiological conventions given that there's no data array to be interpreted (the image)? What having several options buy you in this case? I would enforce scanner coordinates. You can even enforce vectors to be normalized and that will be easy to check for the validator. Also, I'm in favor of having an optional JSON sidecar, with sensible defaults that enable the tsv to be univocally interpreted when the JSON is not provided (i.e., it is not necessary).
This does not apply to BIDS-raw (which is what we are discussing here). I would also be resistant to encode provenance in BIDS-Derivatives, but it could be arguable. @mattcieslak - I think there's an appetite to explore your idea, would you mind drafting a PR to the bids specification proposing what you get from this discussion? Thanks @effigies for the heads-up. |
@oesteban Not sure that would cover any possible diffusion encoding trajectory. I ignore whether there is consensus on how such a trajectory can be represented/described so that it can be formalized into a tabular format. In any case, the |
I think it's great to rethink the best file format for this metadata from scratch. The limitations of The only thing I would be worried about is increasing the number of methods the same piece of metadata can be represented. In other words, there might be a situation when someone develops an app that requires the optional |
@oesteban I was thinking on BIDS derivatives when I was thinking aloud, you
are right. And in that case I would argue for some form of provenance, yes!
But, +1 to tsv and json
…On Sat, Oct 19, 2019 at 5:02 PM Oscar Esteban ***@***.***> wrote:
- could the json have information related to the diffusion file as
well? I mean, for example, {LAS/RAS, [-1,2,3,4]/[1,2,3,4],
neurological/radiological} information that could be used to check the b
values against the file for extra security
Are we sure there's a need for neurological/radiological conventions given
that there's no data array to be interpreted (the image)? What having
several options buy you in this case?
I would enforce scanner coordinates. You can even enforce vectors to be
normalized and that will be easy to check for the validator.
Also, I'm in favor of having an optional JSON sidecar, with sensible
defaults that enable the tsv to be univocally interpreted when the JSON is
not provided (not necessary).
- and maybe history of manipulations of the b-values?
This does not apply to BIDS-raw (which is what we are discussing here). I
would also be resistant to encode provenance in BIDS-Derivatives, but it
could be arguable.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#349?email_source=notifications&email_token=ABCZAV7UQDIIPBQSZIBPVQDQPONYNA5CNFSM4JCIMVXKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBX7DTY#issuecomment-544207311>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABCZAV6RWYHROTDJSIDC6DDQPONYNANCNFSM4JCIMVXA>
.
|
I was thinking of this earlier, and I was imagining the correct response to either accept both formats, or support one and, if only the non-accepted format is available, error with an explicit message. I'm not sure how much this violates existing principles or just adds complexity to BIDS Apps. |
As a side note - the question of how to introduce the new format can be separate from the question of what is the ideal new format. Admins might want to split the discussions for clarity. Now back to logistics. I see the following options:
Option 3 could lead to 4 after some depreciation period. Tooling could be built to assist in updating datasets. |
If you have a RASB tsv file and a dwi nifti file it would be very easy to generate correct bval and bvec files based on the nifti header. It's the other direction that is tricky. If an RASB tsv were available I would use that first. Otherwise the app would fall back to using the bvals and bvecs at the user's own risk. Unless the BIDS app completely forgoes using FSL, bvals and bvecs will need to be created at some point anyways. Also, is this thread suggesting creating a json sidecar for the |
I was proposing a separate json to house derivative metadata for the vectors represented in .tsv. This could include tau, big/small delta, b0 indices, vector orientation relative to image orientation, the gradient table itself with b-matrix / b-vector representations, and units of the b-values (as @arokem suggested). I also agree with @oesteban 's reluctance to include provenance in the json itself, though I do think some type of change log would be useful. |
Thanks very much @mattcieslak for submitting #352. I'm going to lock this thread so that conversation continues there. |
I just found this thread. I made an independent comment about the proposed tsv file. I see now you guys have been discussing this. Which is great. If we all agree. Please disregard my comment. |
Trying to develop diffusion BIDS apps is made significantly more difficult by using the FSL bval/bvec format. A format that is dependent on the image axis (and even then only sometimes) means that a huge amount of effort is required to consistently handle orientation information. These files are ubiquitous and therefore should not be removed from BIDS, but they're a lot of trouble.
I propose adding an optional mrtrix-style ".b" file for each dwi file. These can be robustly generated from dicoms, don't depend on how an image is stored on disk (are in world coordinates, consistent with NIfTI convention), are text-based, and are easy to rotate with other software packages (eg ANTs).
For reference on how difficult these files can be:
DSI Studio, camino, and others have invented their own gradient file formats that are similar to the mrtrix .b format. It would be great if the community can agree on an image-axis-independent file format to be optionally included in BIDS. Even a tsv file with the b values and x, y, z in RAS+ world coordinates would be amazing.
The text was updated successfully, but these errors were encountered: