Derivative reference volumes for 4D series

[effigies]

Your idea

In fMRIPrep, we generate _boldref.nii.gz files from some combination of the source bold file, an associated sbref (if available) and within-space transforms (such as SDC warp). This is used for performing SDC, coregistration, visualization, and as a resampling target for a full BOLD series.

I was initially going to put this into #519 as _boldref and _cbvref, but is it more general? Does this make sense to put into Imaging data types?

Would something like the following ever be generated?

• _dwiref (cc @oesteban, @arokem, @Lestropie, @bids-standard/derivatives-mri-dwi)
• _aslref (cc @patsycle, @HenkMutsaerts)
• _petref (cc @mnoergaard @melanieganz, @bids-standard/derivatives-pet)

[tsalo]

ASLPrep generates aslref files.

[oesteban]

In the dMRI world, I think such a "dwi reference" is typically a $b = 0$ (b0 or bzero). So _dwiref would force people to change their standard. On the other hand, I see great usefulness in standardizing _<modality_suffix>ref as the suffix across modalities (and I would bet a similar concept of "individual alignment reference" may exist even for EEG, MEG or fNIRS)

[effigies]

I think in cases where there is a definite physical meaning, it makes sense to have a specialized suffix. We could describe reference volumes and then simply have a table that maps the raw suffix onto the derived reference suffix:

Data type	Modality	Derived reference
func	bold	boldref
func	cbv	cbvref
dwi	dwi	b0ref
perf	asl	aslref
...

DWI stands out a little, but the concepts are still linked in the spec and will make sense to each modality's practitioners.

[oesteban]

Actually, there are occasions where the reference is calculated with nonzero (but low) $b$ values. I'm not sure there's a big difference between _b0ref and _dwiref while the latter is always theoretically correct and more consistent with the other.

WDYT @yasseraleman ?

On Wed, Jun 28, 2023, 20:23 Chris Markiewicz @.***> wrote:

I think in cases where there is a definite physical meaning, it makes sense to have a specialized suffix. We could describe reference volumes and then simply have a table that maps the raw suffix onto the derived reference suffix: Data type Modality Derived reference func bold boldref func cbv cbvref dwi dwi b0ref perf asl aslref ...

DWI stands out a little, but the concepts are still linked in the spec and will make sense to each modality's practitioners.

— Reply to this email directly, view it on GitHub https://github.com/bids-standard/bids-specification/issues/1532#issuecomment-1611883475, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAESDRRYLSJTOCXK34NIKN3XNRZDHANCNFSM6AAAAAAZXNJ5YQ . You are receiving this because you were mentioned.Message ID: @.***>

[mattcieslak]

I wonder if it would make sense someday to differentiate between b0 and b=0 in bids somehow. Since there are already metadata fields that include b0 in their name and are referring to something totally different. fwiw qsiprep has been writing out _dwiref files, which are the average b=0 images

[oesteban]

If qsiprep already writes _dwiref, I guess that settles it right?

On Wed, Jun 28, 2023, 20:55 Matt Cieslak @.***> wrote:

I wonder if it would make sense someday to differentiate between b0 and b=0 in bids somehow. Since there are already metadata fields that include b0 in their name and are referring to something totally different. fwiw qsiprep has been writing out _dwiref files, which are the average b=0 images

— Reply to this email directly, view it on GitHub https://github.com/bids-standard/bids-specification/issues/1532#issuecomment-1611919421, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAESDRU7RJ7XBBO23IVRO5TXNR4YLANCNFSM6AAAAAAZXNJ5YQ . You are receiving this because you were mentioned.Message ID: @.***>

[effigies]

Yeah, sounds reasonable. I'll write up a PR, as it should be pretty quick.

[effigies]

Just a note that this was not an uncontroversial proposal. Additional input on #1533 would be appreciated.

[mnoergaard]

https://github.com/bids-standard/bids-specification/issues/1532#issue-1779365385 - definitely! We will also have a _petref to indicate the file to be used with registration between PET and anatomical. However, there may be multiple refs present, as one might be using one ref for motion correction, and then another for registration. For example, it is not uncommon for PET preprocessing that a single frame is chosen for motion correction, and then once the data is motion corrected, then the motion-corrected data is either averaged or summed across frames to create a new reference that is then used for co-registration. So we just need to be absolutely clear on the meaning of _petref.

[effigies]

Definitely a good point that the motion correction and coregistration references need not be the same. In BOLD, we generally want to do motion correction with an uncorrected reference, but then use a distortion-corrected reference for coregistration. Assuming we're okay with a common suffix for these two cases, it's just a matter of a desc- field.