Make the code more generalizable to non-human template

[NadiaBlostein]

This PR is about executing steps 1.1 to 1.4 in (see README).

In order to test this PR:

• clone the repository, and get the latest version of this branch

  git checkout nb/preprocess_segment
  git pull

• get the data:

  git clone git@data.neuro.polymtl.ca:datasets/philadelphia-pediatric
  git checkout a99400038a98d074e79e69b955aec6d6fefe2abb
  git-annex get sub-101
  git-annex get sub-102

• edit config file using these info:

  {
     "path_data": "ABSOLUTE/PATH/TO/DATA/"
     "include-list": "sub-101 sub-102",
     "data_type": "anat",
     "contrast": "t1",
     "suffix_image": "_rec-composed_T1w",
     "first_disc": "1",
     "last_disc": "18"
  }

• Test this PR

  • Read the README
  • Test section 1.1 --> 1.4

Before testing this PR, this should be done: https://github.com/neuropoly/data-management/issues/248

Fixes #25, #29, #31, #34, #37, #50, #51

[jcohenadad]

Suggestions about PATH_OUT. If setting PATH_OUT to be PATH_DATA/derivatives/labels, the following will happen:

├── sub-XXX  <---- your dataset
│   └── anat
│       └──sub-XXX_T1w.nii.gz
...
...
└── derivatives
    └── labels
        ├── results  <---- empty
        ├── qc  <---- has stuff
        ├── log  <---- has stuff
        ├── processed_data  <---- empty
        ├── sub-XXX
        │   └── anat
        │       └──sub-XXX_T1w_labelYYY.nii.gz  <---- segmentation and/or disc label to use for template generation
        ...

In general, PATH_OUT would be set to a local directory (eg: scratch space on a cluster), and then, the useful data would be copied back into the dataset under derivatives/labels.

However, I could see the advantages of the proposed approach:

• no need to copy from PATH_OUT to the input data folder (ie: less prone to human error)
• more logging info associated with the processing.

Cons:

• the dataset becomes cluttered with additional processing qc/logging, which is not the end the world...