Design principles

qMRFlow

One-process one-container mapping

Making the most out of a data-driven pipeline engine in terms of modularity is possible using a consistent data standard across similar workflows and abstracting the processes from software selection. qMRFlow achieves the former by adopting Brain Imaging Data Structure (BIDS) for quantitative MRI. The latter is achieved by incorporating neuroimaging software to constituent processes of the pipeline through Docker containers. Nextflow's ability to orchestrate multiple containers opens up the way for easily changing software responsible for executing the tasks (e.g. use an ANTs or an Elastix container for the Alignment process).

1. Maintain Dockerfiles and the Docker Images for qMRFlow preprocessing

Dockerfiles and respective images for preprocessing will be hosted by qMRFlow for traceability:

[qMRFlow]
├── Docker
│   │── $image_name
│   │   ├── Dockerfile
|   |   ├── build.sh 

Built images are pushed to DockerHub qMRLab organization (qmrlab/$image_name:$version).

Nonetheless, any desired Docker image can be easily used for a non-qMRLab process. Visit [to be created] for instructions.

2. Containers for qMRLab processes

qMRLab is the primary software for qMRI processing in qMRFlow. It comes with systematically released Docker Images, ensuring a stable environment that includes a known version of the software.

• Octave-only Dockerized (recommended)

• Octave-only local

• Matlab-only local

• Hybrid

• WIP for MCR-CLI Docker images through qMRWrappers. It will make use of self-hosted Azure pipelines.

Project structure

Naming convention for channels and processes

Naming convention for arguments in config and for binding

Template for USAGE

Handling optional processes

Using qMRWrappers

• latest
• debug
• vx.y.z

Custom convention vs BIDS