You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have been developing a framework for the analysis of large-scale, multi-modal/contrast studies called Arcana (Abstraction of Repository-Centric ANAlysis). Arcana builds on Nipype to encapsulate experimental data and associated analysis methods within Study classes.
Study classes specify:
A collection of related datasets to be acquired from an instrument (scanner). A primary dMRI and its reverse phase-encoding references for example
Products that can be derived from the given acquired datasets, including intermediate ones
Pipelines to derive the derivable products.
Free parameters of the pipelines
Switches to select between comparable pipelines (e.g. segmentation in FSL, ANTs, SPM, etc...)
Placing workflows for neuroimaging analysis within the Arcana framework should help to reduce code duplication, by avoiding the reimplementation of segments that are common to many analysis workflows (e.g. brain extraction), while allowing for specialisation for different MR contrasts through class inheritance. Study classes for multi-modal/contrast experiments can be constructed by the combination of simpler classes into MultiStudy classes, making it feasible to implement complete workflows for complex multi-contrast experiments.
Arcana also abstracts away many of the menial tasks involved with creating workflows such as repository access, data format conversion, session iteration, management of previously computed products, and the storage of provenance (under development).
Repository access in Arcana has been implemented in a modular style that allows the selection of the repository modules at runtime. Repository modules currently exist for
Local. A custom directory format in which datasets stored in a two-tier directory structure organised by subject/visit.
Project
The aim of this project is to add a BIDS repository module to Arcana, and achieving that, develop some BIDS apps using Arcana.
Given that the existing custom local directory format is fairly similar to BIDS it should hopefully not be too much work to convert the Local repository module to store data in BIDS format. The one exception may be tabular data, which there isn't a concept of in Arcana currently.
Since BIDS specifies the names and types of datasets/products within the repository, it will be interesting to see whether it is practical to map Arcana's more general architecture on to it. The Arcana package itself only defines core workflow logic, not the implementations themselves. The workflow implementations we have been working on are in a separate repository (uninspiringly) named NiAnalysis. So some of the work to implement BIDS support may need to be put in there instead.
Proposed Outcomes
The key benefits of adding a BIDS module to Arcana would be:
Simplify the implementation of complex workflows as BIDS apps (hopefully;)
Provide a means to create unified BIDS Apps/XNAT pipelines.
The text was updated successfully, but these errors were encountered:
Submitted by Tom Close
Introduction
I have been developing a framework for the analysis of large-scale, multi-modal/contrast studies called Arcana (Abstraction of Repository-Centric ANAlysis). Arcana builds on Nipype to encapsulate experimental data and associated analysis methods within Study classes.
Study classes specify:
Placing workflows for neuroimaging analysis within the Arcana framework should help to reduce code duplication, by avoiding the reimplementation of segments that are common to many analysis workflows (e.g. brain extraction), while allowing for specialisation for different MR contrasts through class inheritance. Study classes for multi-modal/contrast experiments can be constructed by the combination of simpler classes into MultiStudy classes, making it feasible to implement complete workflows for complex multi-contrast experiments.
Arcana also abstracts away many of the menial tasks involved with creating workflows such as repository access, data format conversion, session iteration, management of previously computed products, and the storage of provenance (under development).
Repository access in Arcana has been implemented in a modular style that allows the selection of the repository modules at runtime. Repository modules currently exist for
Project
The aim of this project is to add a BIDS repository module to Arcana, and achieving that, develop some BIDS apps using Arcana.
Given that the existing custom local directory format is fairly similar to BIDS it should hopefully not be too much work to convert the Local repository module to store data in BIDS format. The one exception may be tabular data, which there isn't a concept of in Arcana currently.
Since BIDS specifies the names and types of datasets/products within the repository, it will be interesting to see whether it is practical to map Arcana's more general architecture on to it. The Arcana package itself only defines core workflow logic, not the implementations themselves. The workflow implementations we have been working on are in a separate repository (uninspiringly) named NiAnalysis. So some of the work to implement BIDS support may need to be put in there instead.
Proposed Outcomes
The key benefits of adding a BIDS module to Arcana would be:
The text was updated successfully, but these errors were encountered: