-
Notifications
You must be signed in to change notification settings - Fork 166
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 MRI derivatives #519
base: master
Are you sure you want to change the base?
Conversation
| `_var_norm` | The time series has been variance normalized | | ||
| `_centered` | The time series has had its mean subtracted | |
There was a problem hiding this comment.
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)?
To continue the conversation from https://github.com/poldracklab/fmriprep/issues/2232#issuecomment-671653585: @effigies said:
@emdupre said:
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? |
Per maintainers call today, two possible routes forward for decomposition statistics are (1) house everything in jsons (as |
## 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. |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@guiomar Sorry, this is extremely late response, but I'm not sure what to do with this. Is your suggestion that we use fMRI derivatives to describe source-localized EEG/MEG maps?
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. | ||
|
There was a problem hiding this comment.
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
regions in the volume. An atlas may be three- or four-dimensional, which affects | ||
the interpretation of the roi index. | ||
|
||
ROI (optional) - For 3D atlases, the ROI label should be numeric, corresponding |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All the examples encode the camel cased roi value in the column name. Does it make sense to duplicate this information in the ROI key in the sidecar?
maintenance note: added a link to the rendered BEP in the top message of this PR. |
Co-authored-by: Julia Guiomar Niso Galán <guiomar.niso@ctb.upm.es>
Codecov ReportPatch and project coverage have no change.
Additional details and impacted files@@ Coverage Diff @@
## master nipreps/fmriprep#519 +/- ##
=======================================
Coverage 87.83% 87.83%
=======================================
Files 16 16
Lines 1356 1356
=======================================
Hits 1191 1191
Misses 165 165 ☔ View full report in Codecov by Sentry. |
|
||
| 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. | |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the actual TR value should be saved in the metadata for distributing the derivative. Otherwise users will need to find the original dataset to get the actual TR for analysis.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The BOLD timing information should be associated with the BOLD file, whether raw or derived. I'm not sure the advantage of duplicating it in timeseries.tsv
. What is your use case?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Extracting time series from ROIs from multiple datasets of different TR, and we potentially need to resample all the data to the same sampling rate for time series model (e.g. autoregressive model).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point, as there may not be an associated BOLD file. But in that case, would you not just set SamplingFrequency
to 1/RepetitionTime
? Along with StartTime
, that's a complete definition.
We should consider the VolumeTiming
case for BOLD. We could see if VolumeTiming
's definition can accommodate an expansion along the lines of "In the case of ROI time series, the VolumeTiming is the timing information for the source BOLD series." Or we could create a SampleTiming
array that makes it explicit. Or we follow PET's lead with blood recordings and add a time
column in seconds.
I'm a little inclined toward the time
column, as that would be a reasonable addition to any timeseries.tsv
, and cover even and unevenly-spaced time series.
It would probably be good to have an explicit rule where timeseries with no associated BOLD series and no time
column SHOULD NOT set "SamplingFrequency": "TR"
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
time
column is the clearest way to me to include this piece of information. I like this idea.
Co-authored-by: Remi Gau <remi_gau@hotmail.com>
In light of #981, specifically the bids-specification/src/schema/objects/suffixes.yaml Lines 672 to 676 in 843f450
bids-specification/src/derivatives/functional-derivatives.md Lines 258 to 269 in 1c79cbc
_timeseries , change to something unambiguous, or will the sidecar and context be sufficient to differentiate the different _motion files?
|
I guess we need to see if registration-derived motion parameters are too different to use the same suffix. I assumed we had a case not too dissimilar and we could treat these as the same type of data, kind of like how you could create synthetic bold series from a forward model, but I have not considered this in detail. |
| Column name | Units | Description | | ||
| ------------------------------- | ------- | ---------------------- | | ||
| `trans_x`, `trans_y`, `trans_z` | mm | Translation parameters | | ||
| `rot_x`, `rot_y`, `rot_z` | radians | Rotation parameters | |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would make sense to also make recommendations for names in raw "physio motion" data for MRI
This PR has been extracted from nipreps/fmriprep#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.Link HTML render of the BEP: https://bids-specification--519.org.readthedocs.build/en/519/derivatives/functional-derivatives.html
Moderators: @effigies @cmaumet