search

bids-standard / bids-2-devel

Discussions and suggestions of backwards incompatible changes to BIDS
https://bids.neuroimaging.io/
Creative Commons Attribution 4.0 International
11 stars 1 forks source link

Addition of scan length in the JSON sidecar #21

Open tsalo opened 4 years ago

tsalo commented 4 years ago

https://groups.google.com/d/msg/bids-discussion/lIH_JZsQ55o/VN-YWbqgBgAJ

I know there's been a lot of discussion about various acquisition timing parameters and how to store them in json sidecars, but one thing that I don't think has come up (though I might have missed it) is how to represent the total length of each scan. It would be nice to define some field like RunLength (expressed in seconds) that lives alongside RepetitionTime. Or alternatively, NumberOfVolumes, which is equally good assuming a constant TR. Personally I would push for making this information mandatory, but at the very least it should be part of the (optional) controlled vocabulary.

I recognize that a field like this is rarely strictly necessary, as the scan duration can usually be computed from the RepetitionTime and information in the image header. But it's quite impractical to require access to potentially very large image files just to access a key piece of information. And unlike some of the other fields in the header, this one is often necessary in contexts that don't involve processing or analysis of the actual images. For example, one should really be able to construct design matrices for all runs in a BIDS project from just events.tsv files, RepetitionTime, and RunLength. It doesn't make sense to me that, e.g., computing collinearity diagnostics for an experimental design should require downloading hundreds of GBs worth of images.

Original authors: @tyarkoni

jbteves commented 4 years ago

This would also allow crawling metadata to quickly determine if a scan is truncated in some way, allowing for easier QC checks.

tsalo commented 4 years ago

@tyarkoni is the idea to make this a required field or an optional one? I think adding an optional field would be BIDS 1-compatible. If the ultimate goal is to make it required, I think we should try making it optional for BIDS 1, and then have the 2.0 proposal be to make it required. 1.X can then be used to test out the field.

EDIT: I see now that this information is in your original post 🤦. What do you think about opening an issue in the main repo for an optional metadata field?

tyarkoni commented 4 years ago

@tsalo feel free to open an issue; I don't have a strong feeling about this one way or the other.