Open jcohenadad opened 5 months ago
JSON sidecars could indeed be used to store this type of information (we can use dictionaries, list of dictionaries etc. see our intranet). Also, if we want to avoid repetition we could use the inheritance principle of BIDS even if I decided not to implement this because of potential confusions (JSON sidecars feel more robust).
For me, the best approach would be to add a description.tsv
file at the root of the folder to describe new keys that we would like to use in the dataset.
Maybe a _sessions.tsv or _scans.tsv file? https://bids-specification.readthedocs.io/en/stable/modality-agnostic-files.html#sessions-file
Sample files:
JSON sidecars could indeed be used to store this type of information (we can use dictionaries, list of dictionaries etc. see our intranet).
To be clear, what I am referring to is the JSON sidecars of the source image (not the derivatives, which this hyperlink in our intranet is pointing to)
Maybe a _sessions.tsv or _scans.tsv file? https://bids-specification.readthedocs.io/en/stable/modality-agnostic-files.html#sessions-file
My issue with these TSV is that they seem to refer more to 'extra' scanning information (eg: type of task performed during the scan, blood pressure), whereas in this case, i need to encode information inherent to the scan, ie: what each sub-volume corresponds to (ie: root-sum of square SNR map, optimum SNR map, B1- sensitivity map, g-factor map, etc.)
To be clear, what I am referring to is the JSON sidecars of the source image (not the derivatives, which this hyperlink in our intranet is pointing to)
The hyperlink is indeed not accurate but the rules about the JSON sidecars are the same. I could add a section about the raw
dataset in our intranet.
The descriptions.tsv
could aswell be used with the raw
data.
We need to describe what each sub-volume of the SNR data correspond to. The info could potentially be in the README, or better, as a JSON sidecar with a custom field.