Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Derivative reference volumes for 4D series #1532

Open
effigies opened this issue Jun 28, 2023 · 10 comments · May be fixed by #1533
Open

Derivative reference volumes for 4D series #1532

effigies opened this issue Jun 28, 2023 · 10 comments · May be fixed by #1533
Labels
derivatives discussion ongoing discussion

Comments

@effigies
Copy link
Collaborator

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?

@effigies effigies added derivatives discussion ongoing discussion labels Jun 28, 2023
@tsalo
Copy link
Member

tsalo commented Jun 28, 2023

ASLPrep generates aslref files.

@oesteban
Copy link
Collaborator

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
Copy link
Collaborator Author

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
Copy link
Collaborator

oesteban commented Jun 28, 2023 via email

@mattcieslak
Copy link
Contributor

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
Copy link
Collaborator

oesteban commented Jun 28, 2023 via email

@effigies
Copy link
Collaborator Author

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

@effigies
Copy link
Collaborator Author

effigies commented Jul 2, 2023

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

@mnoergaard
Copy link
Collaborator

#1532 (comment) - 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
Copy link
Collaborator Author

effigies commented Jul 5, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
derivatives discussion ongoing discussion
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants