Key for noise scans in MRI time series

[handwerkerd]

There are a several situations when someone would collect MRI noise scans by using a standard sequence but with no Radio Frequency excitation. These noise maps are particularly useful for estimating properties of the scanner and sequence that are independent from the object being imaged.

The NORDIC thermal noise reduction method discussed in the following papers for Diffusion & then FMRI are two examples of this. This method has garnered some recent interest and may start to see broader adaption.

• Moeller et at "NOise reduction with DIstribution Corrected (NORDIC) PCA in dMRI with complex-valued parameter-free locally low-rank processing" NeuroImage Feb 2021 https://doi.org/10.1016/j.neuroimage.2020.117539 It's discussed the paragraph beginning with "Following these steps, the noise component of has zero-mean..."

• Vizioli et al "Lowering the thermal noise barrier in functional brain mapping with magnetic resonance imaging" Nature Communication Aug 2021 https://doi.org/10.1038/s41467-021-25431-8

These noise scans are also collected as part of some studies that lean more towards MRI physics. For example this study collected RF excitation off noise scans as one condition: Gonzalez-Castillo et al "Physiological noise effects on the flip angle selection in BOLD fMRI" NeuroImage 2011 https://doi.org/10.1016/j.neuroimage.2010.11.020

I looked, but I don't see any key for storing this information in the JSON files in either the main MRI parameter specification or in the fMRI or diffusion parameters. These noise scans can be collected as a stand-alone run or at the beginning or end of a standard run. I propose adding the following optional key

Key name	Description
RFoffVols	Volumes in a data set where there is no radio frequency excitation which will result in noise scans. Either ("all") if every volume in a scan has no RF excitation or a list of volume numbers where RF excitation is turned off like ("300 301 302 303")

This would fit either in MRI->Sequence Specifics or MRI->RF & Contrast

[effigies]

Is this something that would be indicated in DICOM or need to be manually added?

[jbteves]

If it is, it's somewhere in the Siemens CSA Header, so probably de facto it would need to be manually added.

[yarikoptic]

@neurolabusc any idea on possibility to discover in dicom/bring to bids sidecar?

[neurolabusc]

@handwerkerd can you provide example DICOMs with and without excitation? Feel free to send a link to a google drive archive directly to the email address listed in my avatar.

[handwerkerd]

I can dig up a DICOM to share. That said, my suggestion right now is for a key, not automation. The scans I'm currently acquiring involve a small tweak of the CMRR sequence. The tweak turns off RF for the final X volumes in an normal fMRI scan. I'm not sure if anything is logged in the DICOM header. The same effect can be achieved in a stand-alone scan for the Siemens CMRR sequence by setting the transmit voltage to 0. On GE scanners, there are also a few low-level parameters to change that would turn off the transmit voltage, but for some studies, we've flipped a physical switch to shut off the RF amplifier during a scan.

That's a long way of saying that it might be messy to consistently pull this information from DICOM headers, but I'd be happy if there was just a manual field in the BIDS specs that I could use for now.

[tsalo]

It seems like splitting the affected volumes off into a separate file with a new suffix (or just an acq entity, for an immediate solution) would be easier for tools to work with than a new field identifying affected volumes, much like how single-band reference images have a different suffix (sbref) than their associated BOLD files.

With separate files, tools like fMRIPrep or pybids just need to not select the new filetype (or, e.g., filter out the files with acq-noExcitation). With a new metadata field, fMRIPrep would need to look for the field, split up the time series before preprocessing, and account for the missing volumes in other steps.

WDYT?

[jbteves]

The existing tooling for preprocessing requires that the volumes be all in one file, so the process for users in practice would be the following:

• convert the dicoms to niftis
• split the niftis for archival storage
• Re-join the niftis for actual processing

This seems even more likely to be error-prone in my opinion, and to my knowledge fMRIPrep has no support for NORDIC-style denoising.

[handwerkerd]

My sense is that less the initial DICOM->BIDS conversion messes with MRI data the better. I'd much rather add a field to a json header than turn one 4D DICOM volume into two 4D volumes.

[handwerkerd]

Here's a link to a dicom of a phantom. I've included the readme, the first volume, which is normal data, and the last volume, which is noise.

I did a diff on the output from AFNI's dicom_hdr and no obvious change jumped out. If there's a parameter for the transmit voltage that's what might change between a normal and a noise volume.

[neurolabusc]

@handwerkerd I can not find how to detect this, so outside the scope of dcm2niix. It seems like something you will have to add manually.

[handwerkerd]

I'm 100% fine adding manually, I just wanted to add a key to the BIDS specs so that this info can be consistently annotated across data sets. Perhaps, if this becomes more standard, there will then be a clearer field in dicom headers.

[effigies]

I would suggest that the value be either an array of numbers to be interpreted as 0-based volume indices or the special value "all". A space-separated string that needs its own parsing (however simple) would be more annoying to validate and use.

[tsalo]

I'm still concerned about the idea of using a key instead of a separate file with a different suffix. Here are a few specific reasons:

1. Per @handwerkerd, the noise volumes can be acquired as standalone scans, at the beginning of the run, or at the end. At the moment, NORDIC only appears to support the last option (at least based on my understanding of the docstring here), which means that supporting all three will require changes to NORDIC regardless of how BIDS chooses to support these volumes.
2. Related to the first point, we're going to need to support a separate file suffix for standalone noise scans in the future anyway, right?
3. The noise scans aren't BOLD-weighted, correct? It seems misleading to place them in a file with the "bold" suffix. This is something that often came up in relation to BEP001 and file collections. For example, see #654, where T1w is not accepted as a valid suffix for multi-echo MPRAGE scans.
4. Adding a metadata field that indexes non-BOLD volumes within an fMRI run also adds an entirely new element for tools to work around, as well as a very open-ended mechanism for any future within-run sequence modifications. Supporting a new metadata field won't be as straightforward for tools to deal with as updating a BIDS filter file to exclude files with a certain entity or suffix- all BIDS apps for processing DWI or fMRI data would need to account for this specific field in the future.
5. This proposal would organize fMRI/DWI files in a very similar manner to ASL files. ASL has different volume types in a time series within a single 4D file. It requires a separate aslcontext.tsv file to handle this. It seems strange to me to implement a very different mechanism for what is basically the same concern (varying volume types in a time series). I would very much like to avoid adding a boldcontext.tsv to the specification, but that seems more consistent with the specification than a metadata field to me.

This seems even more likely to be error-prone in my opinion, and to my knowledge fMRIPrep has no support for NORDIC-style denoising.

@jbteves, I agree that that's a point in the pipeline where errors could be introduced, but you need to split up and rejoin your files anyway if you acquire your noise volumes in a standalone scan or at the beginning of the run. At least as long as NORDIC only supports noise scans at the end of runs. Also, I think it would be preferable if we made sure that data that could be denoised with NORDIC could still be processed with fMRIPrep without running NORDIC. Do you know if afni_proc.py would work on runs with noise volumes?

My sense is that less the initial DICOM->BIDS conversion messes with MRI data the better. I'd much rather add a field to a json header than turn one 4D DICOM volume into two 4D volumes.

@handwerkerd I agree that it would be best if the conversion manipulates the data as little as possible. On the other hand, BIDS tends to lean toward splitting data with inherently different parameters or contrasts, even when those data are acquired within the same run. For example, BIDS keeps phase and magnitude data separate instead of in a single complex-valued image.

[handwerkerd]

@tsalo I want to clearly write out the two options being proposed. Since the key info cannot be automatically extracted from the DICOMs there are two proposals for the manual step. Common part: DICOM -> single-file BIDS-ish Manual option 1: Add one key-value pair into the JSON Manual option 2: Split the single file into two files with two different suffixes

I feel like option 1 would be simpler for me and that's my strong preference, but option 2 is reasonable. If Option 2 fits better with the general BIDS ethos, I understand and will defer to the people who will likely add this to BIDS.

afni_proc.py can handle the data as is, with no problem. Just add the -tcat_remove_last_trs 5 option and it removes the volumes before processing begins. As of now, NORDIC is designed to be applied on data right off the scanner so you'd feed it the data + noise volumes and it would output noise-reduced data without the noise volumes. That would then be fed into another pipeline.

FWIW, You've also hit one of my big aggravations of the BOLD suffix and the suffix approach in general. That discussion on multi-echo T1w could also be applied to multi-echo fMRI. Depending on echo timing, should we exclude the BOLD suffix from the first echo fMRI volume? If someone collects signal echo fMRI with the same short echo should they use the BOLD suffix? There's not a clean answer to this, but I'm just highlighting inherent messiness. Similarly, magnitude + phase ARE the exact same parameters! The only (very good reason) reason to not save complex data in a single volume is that most programs can't handle complex data.

[handwerkerd]

We're setting up a script for processing data. Given this discussion, it sounds like split files are preferred. From my understanding, for a single echo of a multi-echo sequence, a single acquisition would result in the following file names and all these files would have nearly identical information in their json files. There would be no differences in the bold vs noise json files:

sub-01_task-awesomestudy_run-1_echo-1_part-mag_sbref.json
sub-01_task-awesomestudy_run-1_echo-1_part-mag_sbref.nii
sub-01_task-awesomestudy_run-1_echo-1_part-phase_sbref.json
sub-01_task-awesomestudy_run-1_echo-1_part-phase_sbref.nii

sub-01_task-awesomestudy_run-1_echo-1_part-mag_bold.json
sub-01_task-awesomestudy_run-1_echo-1_part-mag_bold.nii
sub-01_task-awesomestudy_run-1_echo-1_part-phase_bold.json
sub-01_task-awesomestudy_run-1_echo-1_part-phase_bold.nii

sub-01_task-awesomestudy_run-1_echo-1_part-mag_noise.json
sub-01_task-awesomestudy_run-1_echo-1_part-mag_noise.nii
sub-01_task-awesomestudy_run-1_echo-1_part-phase_noise.json
sub-01_task-awesomestudy_run-1_echo-1_part-phase_noise.nii

@tsalo, is this what you're currently preferring? I can start using this if it's what's likely to get formally added to the BIDS specs.

[tsalo]

That's kind of what I was thinking of. I figured we could come up with a more technical suffix though (e.g., efref for excitation-free reference or something). I'd also like to get @effigies's thoughts on that idea before moving forward with it.

[effigies]

@tsalo That sounds reasonable to me, and I agree that noise is probably too generic a suffix. efref is as good as anything I can think of, but possibly those working with the data can think of something more instantly recognizable?

[handwerkerd]

I couldn't remember what efref stood for between yesterday at today. If capitalization is allowed, I'd prefer noRF otherwise, noexcite. ref doesn't really add much meaning.

[effigies]

noRF sounds good to me.

[tsalo]

I think it's worth it to open a PR to add the noRF suffix. Does anyone have any issue with that?