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

BEP 012: Functional derivatives #519

Draft
wants to merge 3 commits into
base: master
Choose a base branch
from
Draft

BEP 012: Functional derivatives #519

wants to merge 3 commits into from

Conversation

effigies
Copy link
Collaborator

@effigies effigies commented Jun 30, 2020

This PR has been extracted from #207, following the incorporation of BEP 003 - Common Derivatives (#265).

I've gone through a first pass of bringing it into conformation with BEP 003. I think there are no direct conflicts, so I would like to open this up to community comment.

I think the @bids-standard/derivatives-electrophys team should have a look at the _timeseries.<ext> components. I suspect that at least some of this could be written more generally to ensure that we make BEP021 a natural extension rather than an awkward re-architecting.

Moderators: @effigies @cmaumet

| `_var_norm` | The time series has been variance normalized |
| `_centered` | The time series has had its mean subtracted |
Copy link
Member

@tsalo tsalo Jul 7, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would X_centered_var_norm then be a substitute for something like _z when z-scoring values? Or would users be more likely to create a new suffix for additional standard transformations like z-scoring?

Also, if the values are underscore-delimited, could they be converted to camel-case to make it easier to separate them (especially as new values are added)?

@tsalo
Copy link
Member

@tsalo tsalo commented Aug 11, 2020

To continue the conversation from nipreps/fmriprep#2232 (comment):

@effigies said:

Regarding the decomposition.json, it looks like a table serialized to JSON, so I wonder why we wouldn't target TSVs. The derivatives spec, while a useful tool for standardizing common things, is inherently incomplete, and tools are allowed to produce unspecified derivatives. It makes more sense to me to spend a year or two with things in an unstable but useful state than wedging data into a specified but awkward structure.

@emdupre said:

I think we've generally aimed to build off of the fMRI derivatives BEP, which currently recommends a decomposition.json file specifically. Though I may have misunderstood how that file was originally envisioned !

Personally, I like having the metadata file in a JSON rather than a TSV, but that's only because it feels more "BIDS-y" to me. Though I'm certainly not the expert in this discussion on that 😸 All that to say, and seconding @\oesteban: Maybe we should have this conversation on that specific part of the derivatives BEP ?

Personally, I'd like to see these decomposition metrics and classifications supported in as BIDS Derivatives-compatible a manner as possible, since adding metadata to decompositions is very common, especially if you want to retain as much information as possible (e.g., variance explained for PCA components in CompCor, AROMA classifications, etc.). If a TSV targeting the decomposition JSON, with its own JSON describing the TSV's columns, would be the best way to do it, then could that be supported here?

@tsalo
Copy link
Member

@tsalo tsalo commented Aug 18, 2020

Per maintainers call today, two possible routes forward for decomposition statistics are (1) house everything in jsons (as tedana currently does) or (2) add a new suffix for TSVs containing these stats (e.g., _decompStats.tsv). The former is completely valid under the current rules, and the latter can always be adopted later, so the consensus was to stick with a json file for the immediate future, for both fMRIPrep and the Functional Derivatives BEP.

## Functional derivatives maps

A derivative map is a measure derived from a functional series, mapped onto spatial
locations as defined by voxels in a volume or vertices on a surface.
Copy link
Collaborator

@guiomar guiomar Oct 26, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are these the only ways to define a location? If we have an electrode, for example, its localization can't be Cz, must be its coordinates, right? Are coordinates also included in this definition?

| Field name | Definition |
| :---------------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------- |
| SamplingFrequency | REQUIRED. Sampling frequency (in Hz) of all columns in the file. Special value `"TR"` indicates one sample per volume of a corresponding BOLD series. |
| StartTime | OPTIONAL. Start time in seconds in relation to the start of acquisition of the first volume in the corresponding imaging file (negative values are allowed). |
Copy link
Collaborator

@guiomar guiomar Oct 26, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
| StartTime | OPTIONAL. Start time in seconds in relation to the start of acquisition of the first volume in the corresponding imaging file (negative values are allowed). |
| StartTime | OPTIONAL. Start time (in seconds) in relation to the start of acquisition of the first volume in the corresponding imaging file (negative values are allowed). |

headers indicating the name of the time series.
In the case where every voxel has a time series (i.e., voxel-wise regressors,
as in ANATICOR), then the time series should be saved as a NIfTI file.

Copy link
Collaborator

@guiomar guiomar Oct 26, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reminder link of available atlases

@@ -0,0 +1,390 @@
# Functional derivatives

Copy link
Collaborator

@Remi-Gau Remi-Gau Jan 30, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There probably should some recommendations on how to name the desc label in the case that people have several func contrasts (for example suffixe cbv).

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

Successfully merging this pull request may close these issues.

None yet

5 participants