[ENH] Add noRF suffix for MR excitation-free noise scans

[tsalo]

Closes #1024.

Changes proposed:

• Add noRF suffix to schema, representing excitation-free noise scans. These scans are typically acquired as additional volumes at the end of an fMRI run, for use in denoising with a tool like NORDIC. This proposes splitting them out into separate files, for better compatibility with tools.

[tsalo]

@handwerkerd I'd love your input on the description.

[effigies]

This LGTM. It seems like this needs to be done manually, but worth looping in @neurolabusc and @yarikoptic for any possible implications for dcm2niix/heudiconv.

[neurolabusc]

@tsalo can you provide exemplar DICOM validation datasets as sourcedata? It would be great to see examples from the major manufacturers (GE, Siemens, Philips). It is very hard to support a specification without concrete examples. BIDS fields are often defined by experts that have a clear vision of what is needed, but there can be unintended consequences if the implementation is left to end users that have no idea what this data looks like.

[handwerkerd]

As a separate file, should there be a key(s) that denotes whether a noRF scan is linked to another scan and, if they were collected as part of one acqusition, whether it was at the beginning or end of the scan.

[handwerkerd]

@tsalo can you provide exemplar DICOM validation datasets as sourcedata? It would be great to see examples from the major manufacturers (GE, Siemens, Philips). It is very hard to support a specification without concrete examples. BIDS fields are often defined by experts that have a clear vision of what is needed, but there can be unintended consequences if the implementation is left to end users that have no idea what this data looks like.

Here's some data shared from when this was an issue: #1024 (comment)
That is from a tweaked version of the CMRR Siemens multiband sequence. At that point, this was still a bit hacky from the pulse sequence side of things so it's unclear if there would be a clear and consistent field to use. At least for now, it might be somethings uses might need to manually specify for after automated dicom conversion.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 87.88%. Comparing base (01025da) to head (fc2f435).

❗ Current head fc2f435 differs from pull request most recent head cd52516. Consider uploading reports for the commit cd52516 to get more accurate results

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #1451      +/-   ##
==========================================
- Coverage   87.92%   87.88%   -0.04%     
==========================================
  Files          16       16              
  Lines        1375     1354      -21     
==========================================
- Hits         1209     1190      -19     
+ Misses        166      164       -2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[tsalo]

As a separate file, should there be a key(s) that denotes whether a noRF scan is linked to another scan and, if they were collected as part of one acqusition, whether it was at the beginning or end of the scan.

I assumed that noRF scans would operate similarly to sbrefs, in that you wouldn't have one without an associated "primary" scan. One could also conceivably acquire an sbref at the beginning or end of the primary scan, or even in a separate scan, but we don't use metadata to explicitly encode that information. Is it necessary for noRF scans?

@tsalo can you provide exemplar DICOM validation datasets as sourcedata?

I also have some DICOMs from the CMRR sequence, with five echoes and magnitude + phase reconstruction. They're available at https://upenn.box.com/s/cgoc7851m3uo4yinxqxqlfv53em0n75b.

[handwerkerd]

It is definitely possible to have one without a specific primary scan. For example, there are several studies that collect a single stand alone noise scan during a scanning session. Besides noRF it would have identical parameters to all the other bold runs in a session. One could arbitrarily link it to one of the bold runs, but that wouldn't be necessary.

Within the existing bids framework, I guess that would mean giving the noise scan a distinct run identifier and, if it's collected as part of a bold run it would have have the same run identifier. From my understanding, no changes to specs would be needed for this.

Since it might mess up stimulus timing later, it would be useful, but not essential to know if the noise scans were collected at the beginning or end of a run.

[tsalo]

@handwerkerd in that case, maybe we should recommend using an IntendedFor field in the noRF's metadata.

I think events files should be adjusted as part of the BIDSification process, rather than within the BIDS dataset, but I'd like to get @effigies' thoughts on it.

[effigies]

I have little context for how these files are used, so my thoughts are more based on experiences with "associated data" files in BIDS, such as fieldmaps.

I think IntendedFor is one of my least favorite aspects of BIDS, as it encodes processing decisions within the raw data. I much prefer the B0FieldIdentifier approach to indicate which files can be used collectively to estimate a fieldmap, and then the task is to associate a fieldmap to a file. (The B0FieldSource metadata still encodes processing decisions in data, which I don't like, but at least they are associated in the BOLD file's metadata. I would prefer it if there were some standard way to map files in the bids-app protocol.)

If the idea here is to use the nearest noRF scan to aid in processing a given file, it seems like the simplest way to encode that is through the acq_time column in scans.tsv. The selection process is then part of the algorithm of the correcting tool. If you really need to encode intent, then I would suggest following the lead of B0FieldIdentifier and only use IntendedFor if you are unable.

[effigies]

Also: What files might be corrected by this, in addition to BOLD? Should we add it to DWI, ASL, anat, etc?

[tsalo]

I much prefer the B0FieldIdentifier approach to indicate which files can be used collectively to estimate a fieldmap, and then the task is to associate a fieldmap to a file. (The B0FieldSource metadata still encodes processing decisions in data, which I don't like, but at least they are associated in the BOLD file's metadata. I would prefer it if there were some way to map files )

That sounds reasonable... maybe something like ThermalNoiseIdentifier and ThermalNoiseSource? @handwerkerd WDYT? I also agree that using the scan time can be a good heuristic for defining the field, as folks often do with field maps.

Also: What files might be corrected by this, in addition to BOLD? Should we add it to DWI, ASL, anat, etc?

I know it has been applied to DWI data at minimum, but I'm not sure about other modalities. It's meant as a measure of the thermal noise level, I believe, so I can imagine it being useful in other modalities. At least ones that typically involve some kind of denoising over time (e.g., ASL)... but I'm very new to this acquisition, so I could be wrong.

[handwerkerd]

I think this might be getting overly complex (partially my fault). Any MRI sequence can be collected with noRF and this can be useful to measure the noise floor for any pulse sequence. In practice, you can tell exactly what it is is linked to because all the other parameters should match.

The only thing that makes this messy is that there is currently a single pulse sequence that collects some noise volumes a the end of an fMRI run so that a dataset will have multiple noise scans with each one collected as part of a specific run. The only reason we would need to know if it is from the beginning or end of a run is because BIDS requires actively cutting up the runs to separate the noRF from the normal volumes, which risks creating timing issues. As long as a script is included that documents what is done, this run order might be something that's not worth specifying in BIDS.

[effigies]

BIDS requires actively cutting up the runs to separate the noRF from the normal volumes

I'm not sure that's true, but I guess that would reopen discussion of #1024 (comment), and this has apparently been open for a year, so I'll try to move forward and not look too much backward.

As long as a script is included that documents what is done, this run order might be something that's not worth specifying in BIDS.

This might be best until there are are enough such scans that it is worth developing a consensus on how to encode it. I think we could still suggest calculating the two split files' acq_times from the original BOLD file's acq_time and duration, as that does not require introducing any more new concepts to BIDS.

[handwerkerd]

Given the discussion with @effigies, the actual content of the PR is fine with me. I just noticed a few typos.

FWIW, part of the challenge here is that BIDS is trying to define pulse sequences by application so that a single band fMRI time series is labeled bold while the exact same sequence is labeled sbref if it's acquired before a multiband sequence and it has a different label if it's acquired as a b0 scan during a diffusion run, while a multi-echo sequence is bold even if the earliest echoes shouldn't be called bold-weighted. That's how we get into requiring a label in a file name for what really should be a parameter in the header. Unfortunately, this PR really is the best solution given the current overall set-up of BIDS.

[ericearl]

I got pinged on this and the changes LGTM. But I don't know the schema language well enough to know if this would break anything. @effigies or @rwblair this looks okay, right? Does the specification have text referring back to this or would that need a separate PR?

Contents changed

[effigies]

All this PR will do right now is make noRF suffix valid anywhere bold is valid. It does not provide for the mod-<label> entity that is included in the description, which seems like a problem. There will be no required metadata for this file. Is that okay?

[tsalo]

I'll add the mod entity now. I see noRF files are similar to sbrefs in that they should generally rely on an implicit connection to the original file, so I can't think of any metadata they would need.

[tsalo]

I changed the mod- examples to cbv and bold, but I can add noRF as a valid suffix for other MRI rulesets if folks want that.

[effigies]

Shows up in https://bids-specification--1451.org.readthedocs.build/en/1451/modality-specific-files/magnetic-resonance-imaging-data.html#task-including-resting-state-imaging-data.

[tsalo]

Should I start the 5-day clock now that there are two approvals?

[tsalo]

@bids-standard/raw-mri @bids-standard/raw-mri-func This is now open for voting and will be merged on Wednesday, April 24 if no one raises any major concerns.

In order to vote, please add a 👍 or 👎 reaction to this comment. If you vote 👎, it would be really helpful if you could post a follow-up comment explaining why.

[tsalo]

Closing out the vote and merging.

[bpinsard]

Joining the party a bit late and have more technical questions about implementing noRF scan (that I just learned about):

• In the data that @handwerkerd shared here Key for noise scans in MRI time series #1024 (comment) it seems that it is exported in the same series as the main acquisition (not like the SBRef). So running it through heudiconv/dcm2niix will not produce a separate nifti file by default, unless these are modified to split it based on the dicoms. However, looking at the 2 dicoms, there seems to be no dicoms/CSA/MRProtocol tags that allow to distinguish the noRF from the regular acquisition.
• Is this a CMRR-MB feature only, or is it possible with product sequence ? I can't find how that option can be enabled in the docs here https://www.cmrr.umn.edu/multiband/Multi-Band_C2P_Instructions_R017.pdf . Is that a hidden option that needs to be activated through the config file?
• Having more info, we could then get back to CMRR folks to ask if this dicom could be exported as a separate series, similar to SBRef, to allow more straightforward BIDS-conversion.

Thanks!

[bpinsard]

I think I found an answer to my question https://github.com/CMRR-C2P/MB/wiki#extra-shadowy-shadow-header-parameters

[tsalo]

it seems that it is exported in the same series as the main acquisition (not like the SBRef). So running it through heudiconv/dcm2niix will not produce a separate nifti file by default, unless these are modified to split it based on the dicoms. However, looking at the 2 dicoms, there seems to be no dicoms/CSA/MRProtocol tags that allow to distinguish the noRF from the regular acquisition.

Unfortunately, the only solution I've come up with is to do the split after running heudiconv.

Is this a CMRR-MB feature only, or is it possible with product sequence ?

Sorry, I don't know. I only know of it in the context of the CMRR-MB sequence.

we could then get back to CMRR folks to ask if this dicom could be exported as a separate series

I hadn't considered asking CMRR to separate the series. That would be awesome.