BIDS support for VASO sequences

[Remi-Gau]

Transferring here part of a discussion that happened on a slack workspace: to give it more visibility.

Context:

• VASO sequences output is an alternation of "blood-nulled" and "blood-not-nulled" contrasts (sometimes also called tagged and control). "not-nulled" is regarded as BOLD and "nulled/not-nulled" gives VASO contrast (see Huber et al 2014, eq 3).
• What is usually called VASO and BOLD are calculations based on the tag and control and there are several ways to make that calculation, so they’re technically "derivatives", not “raw” data from a BIDS point of view. Similar to T1maps from MP2RAGE when they are not reconstructed by the scanner.
• Currently BIDS raw assumes a single contrast per time series and supports bold and cbv
• Supporting contrast-mixed VASO time series in raw dataset would require additional metadata (for example: the volume for each contrast may have different TR)
• Most pipelines are usually interested in ingesting the BOLD and VASO "derivatives" time series, so what's needed is something to signify what data people actually tend to process

Further comments

there really needs to be something in between “raw” and “derivatives” to organize this entire class of data. It should include some information on how these intermediate volumes were calculated (a reference, code, or equation), but it should live in a place that’s more stable than what may typically end up in a derivatives directory.

It would be great if you (or someone) could make the contrast-mixed VASO time series compatible with BIDS.
I think there would be only one single meta parameter needed.
"delay between time series in milli seconds": this parameter can take care of many peculiarities of VASO as it is being used currently. E.g. if this number is positive, it means that VASO is first, if negative it means that BOLD is first. If this number is not exactly 1/2 of the pair TR, it means that the pair of images are acquired with an asymetric temporal acquisition scheme. If the parameter is smaller than the volume acquisition time, it means that the sequence uses segmented acquisition trajectories of true interleaved acquisition of VASO and BOLD alternating in k-space segment by segment. (From @layerfMRI)

---

Huber, L., Ivanov, D., Krieger, S. N., Streicher, M. N., Mildner, T., Poser, B. A., Möller, H. E., & Turner, R. (2014). Slab-selective, BOLD-corrected VASO at 7 Tesla provides measures of cerebral blood volume reactivity with high signal-to-noise ratio. Magnetic Resonance in Medicine, 72(1), 137–148. https://doi.org/10.1002/mrm.24916

[Remi-Gau]

Tagging @ofgulban

[ofgulban]

I wonder if the BIDS task events text files _events.tsv can be repurposed to indicate "blood-nulled" & "blood-not-nulled" alternations, in addition to the stimuli/tasks. This file would also cover asymetric temporal acquisition schemes.

Thanks or tagging @Remi-Gau .

[Remi-Gau]

This could be one way of keeping track of it by having the trigger for each type of volume but better have it in the side-car json file.

Probably by having something similar to the volume timing:

https://bids-specification.readthedocs.io/en/latest/99-appendices/14-glossary.html#volumetiming-metadata

https://bids-specification.readthedocs.io/en/latest/04-modality-specific-files/01-magnetic-resonance-imaging-data.html#required-fields

[tsalo]

Perhaps I'm misunderstanding, but the organization and labeling sounds very similar to how ASL data are organized (e.g., the aslcontext.tsv file. Would the same structure be appropriate for VASO data? Namely, a 4D file with alternating volume types, a context file with the types labeled, and perhaps even some of the same timing-related metadata fields, with or without VolumeTiming.

[Remi-Gau]

I think you are correct that could also be a possibility.

though in this case, I suspect in this use case we also want to find a way to specify the "proximate" derivatives that most users would be interested in using directly.

[ofgulban]

@tsalo 's pointer to the aslcontext.tsv file makes sense to me. I think this example fits to VASO raw timeseries quite well.

I guess what @Remi-Gau points to is that once the VASO correction (basically what people analyze) is performed (blood-nulled/blood-non-nulled), the number of time points reduces to half while the implied TR is doubled. Therefore the derived timeseries labels need to be updated. Are you referring to this issue @Remi-Gau, or am I getting sth wrong ?

[Remi-Gau]

yup pretty much: the idea is that if you shared the vaso corrected it comes with enough metadata to be a standalone dataset if need be.

Note that unless I am mistaken this might also mean a resampling of the events.tsv if the nulled and non-nulled have different TRs.

[ofgulban]

Right, the events.tsv needs to be updated from "blood-nulled" & "blood-not-nulled (aka BOLD)" alternations to VASO. I think what can be confusing is the decision of whether cutting down the number of time points to half or "filling in the gaps" by interpolation to make the time series as long as the initial raw data. I am not sure what is the current most common approach when dealing with this issue.

In addition, the "blood-not-nulled (aka BOLD)" volumes can be separated into a derived folder, so that they only contain the BOLD time series (as they come for free, I think most people end up analyzing these together with VASO). The decision to update the labels and events.tsv will be the same as VASO derivatives.

[ofgulban]

Tagging @sdres as a VASO + BIDS user.

[tsalo]

though in this case, I suspect in this use case we also want to find a way to specify the "proximate" derivatives that most users would be interested in using directly.

Perhaps something like this:

sub-01_task-rest_vaso.nii.gz  <-- Mixture of nulled and non-null volumes
sub-01_task-rest_vaso.json  <-- VolumeTiming specified
sub-01_task-rest_vasocontext.json  <-- Order of nulled/non-nulled volumes specified
sub-01_task-rest_rec-corrected_vaso.nii.gz  <-- VASO-only data
sub-01_task-rest_rec-corrected_vaso.json  <-- VolumeTiming specified
sub-01_task-rest_rec-bold_bold.nii.gz  <-- BOLD-only data
sub-01_task-rest_rec-bold_bold.json  <-- VolumeTiming specified
sub-01_task-rest_events.tsv  <-- Just task information. No information about VASO.

WDYT? rec-corrected_vaso could probably be replaced with a different suffix, if that's more interpretable.

Note that unless I am mistaken this might also mean a resampling of the events.tsv if the nulled and non-nulled have different TRs.

One reason I would prefer to have volume information in a separate file based aslcontext template is that there would be no need to change the events file. The events file would just have task information, which uses timing in seconds, rather than volume numbers.

[ofgulban]

I like this organization, I could not make up my mind on not using the events file, there might be cases where it could be handy to keep the acquisition labels in milliseconds and together with the task/stimulation, and this can be more transparent to the users (e.g. less MRI-savy users will be aware that the volumes can be of different contrasts as this is quite different than conventional fMRI). I think maybe the names can be improved to better correspond to the paper. What about:

sub-01_task-rest_vaso.nii.gz <-- Mixture of nulled and non-null volumes
sub-01_task-rest_vaso.json <-- VolumeTiming specified
sub-01_task-rest_vasocontext.json <-- Order of nulled/non-nulled volumes specified
sub-01_task-rest_rec-bold_corrected_vaso.nii.gz <-- VASO-only data
sub-01_task-rest_rec-bold_corrected_vaso.json <-- VolumeTiming specified
sub-01_task-rest_rec-bold.nii.gz <-- BOLD-only data
sub-01_task-rest_rec-bold.json <-- VolumeTiming specified
sub-01_task-rest_events.tsv <-- Just task information. No information about VASO.

@Remi-Gau , @sdres any thoughts?

[Remi-Gau]

sub-01_task-rest_rec-bold_corrected_vaso.nii.gz <-- VASO-only data
sub-01_task-rest_rec-bold_corrected_vaso.json <-- VolumeTiming specified

Those are not BIDS valid names, because underscore can only be used to separate entities (key-value) pairs or before the final suffix (see here for a colorful example).

How about:

sub-01_task-rest_rec-boco_vaso.nii.gz
sub-01_task-rest_rec-boco_vaso.json

My 2 cents is that at this stage is trying to build one (or a few) mini-datasets (they can be mostly filled with dummy / empty nifti files) as concrete suggestions and gather feedback from other VASO users.

[ofgulban]

I like *rec-boco_vaso* suggestion the most. Cool, lets stick with this unless someone disagrees.

[ofgulban]

Tagging @kenshukoiso, I think he has a nice 1-2 brains VASO dataset, and also has some experience with BIDS + VASO (see this: https://openneuro.org/datasets/ds003216).