Support templates other than MNI152NLin2009cAsym #1558
Comments
oesteban
added
impact: high
|
cc @satra |
|
more than other templates, i think i would want to extract individual space data. that being said, custom/other templates would likely be helpful to extend fmriprep to other workflows (e.g., infant mri) |
|
Absolutely. I pinged you because now |
|
this describes the surface mappings. so if the templates are in place, creating the workflows is not that complicated. |
|
Necessary surfaces were already there (L, R). Although discouraged (the recommendation is to align the individual's surfaces to fsLR's via MSM), the files I included into the fsLR template are intented to implement route C of the document. For the recommended way (or at least more accurate procedures involving surface native spaces), people should use ciftify (wdyt @edickie?). |
|
Seems like the best plan for the time being. Sorry I haven't had time to contribute to this lately. I'm pretty swamped till May. |
|
Wait aren't you doing route D in the doc? |
|
if obviously we will not be able to do single step interpolation, but at least in two steps going from bold to individual surface and then to |
|
I'll be using the EDIT: that is kind of option A of the document, but skipping the fsaverage-to-fsLR step with the workbench. |
A new spatial normalization workflow has been outsourced from the main anatomical workflow - closes nipreps#1. This addition is crucial for the implementation of nipreps/fmriprep#1558 and more generally, nipreps/fmriprep#1588.
…ataSink`` Permit setting a list of ``allowed_entities`` at the instantiation time of ``DerivativesDataSink``s so that it is possible to create arbitrary, dynamic BIDS entities for the output file name without confusion with dynamic metadata keys. The reason to add this feature is to allow a more flexible interface for derivatives generated via iterables in the context of nipreps/fmriprep#1558.
This refactor is necessary in the context of nipreps/fmriprep#1558 in order to allow a more flexible generation of reports. The report factory now depends on a BIDSLayout, with a new configuration file (by default, this is ``niworkflows/viz/figures.json``) Ordering of tasks, runs, etc happens at query time. The general structure of the reports is still handled by a ``config.json`` object, in which the BIDS entities to be queried are listed (replacing the former regex patterns). The overal Jinja template and the config file now look a bit cleaner with several simplifications.
This is a large refactor using two major inter-related features: - Uses nipreps/smriprep#72 and its continuation within nipreps/smriprep#75 to permit the specification of several spatial normalization targets (close nipreps#1558). - Uses the refactor of Reports generation of nipreps/niworkflows#344, which enables rendering reports with several normalization spaces. Correspondingly, report generation code and config files have been removed. Correspondingly, the new interface for ``--output-spaces`` is also incorporated (close nipreps#1588).
Now that TemplateFlow is up and seemingly running okay, it is time to open up the
--templateoption and allow additional template keywords.This is related to nipreps/smriprep#50 where the CLI interface will be reconsidered and where we will come up with a solution for people who want to run normalization to two or more templates.
The text was updated successfully, but these errors were encountered: