Deal with unwanted TRs or TRs with uneven spacing

[RayStick]

At the moment, phys2bids assumes that TRs within each scan have even spacing. It also assumes that all the TRs in your file are correct and complete, and sometimes this may not be the case.

Detailed Description

For some MRI scans with functional contrast (e.g. Arterial Spin Labelling) there will often be some "prep scans" before the main acquisition, that have corresponding triggers, but these triggers may have different spacing to the triggers in the main scan that follows. For example, before an ASL acquisition, we often we run a “calibration scan” for the purposes of perfusion quantification: normally a single volume with the same acquisition parameters but without tagging the blood and with a really long TR so magnetization is fully relaxed. There will be other types of scans where they could be similar prep scans with different TR spacing - maybe we want to ignore these TRs (more likely) or we want to include them in our phys2bids output (less likely).

Context / Motivation

This would allow us to support different types of functional MRI scans, that are very relevant to using physiological recordings alongside fMRI, considering ASL gives you a more interpretable (and quantifiable) physiological measure compared to BOLD.

Aside from uneven triggers that are a consequence of the scan sequence (e.g. ASL), we could also have unwanted triggers due to errors. Or we could have places where triggers are missing.

Possible Implementation

I need to think more about a possible implementation.

@tsalo's #219 may be relevant here, which is less dependent on TR.

[tsalo]

To clarify- #219 still needs an estimate of total scan duration, and currently uses RepetitionTime * number of volumes. However, it would be easy enough to try extracting the AcquisitionDuration metadata field for each scan, if it's available. For more information about this field and when it should be available, please see here.

[RayStick]

Thanks @tsalo!

[tsalo]

@RayStick, I'm not very familiar with BEP005, but does it require that the calibration scan(s) be split into a separate file? Are those the same as the m0scan suffix in the BEP?

[RayStick]

Yes, the M0scan refers to the calibration scan.


However, there are 3 main approaches to ‘calibrating’ the asl data:

1. Use a set numerical value 

2. Use an M0 scan (either acquired as a separate file or acquired within the main asl scan, normally the first volume)
3. No M0 scan is acquired. One is constructed by taking an average of all the control images from the main asl scan. This is only valid if there was no background suppression or pre-staturation pulses.



The calibration option used (1,2 or 3) needs to be specified in the main asl json file.

It seems like it is equally valid for the M0scan to be a separate file or be contained within the main asl file



“Currently both the acquisition of the m0scan within the asl time series, as well as acquiring it separately is equally valid.”

If the M0scan is included in the main asl file

“its position within the time series should be specified in the *_aslcontext.tsv file, and the M0 field should be included in the *_asl.json.”

If the M0scan is acquired separately it should not be included in the above tsv and json, but have its own json file.

Let me know if that answers your question! Happy to explain more, if needed.

[tsalo]

Thanks, that clarifies things perfectly.

[RayStick]

To add a bit of context to this file (as I just worked it out) - the first trigger corresponds to M0 volume, the second trigger corresponds to a volume I want to ignore, and the rest of the triggers correspond to alternating tag-control volumes. But these volumes are all contained within the same NIFTI file, so this is a bit complex ...