Ingression should be its own module

[cindyhfls]

The current --input-type calls the respective ingression files but they are hardcoded to only work with a specific data and specific version of processing (e.g. in the HCP file, it checks for folders that ends with "LR" and "RL" which might not exist in other acquisition/file naming). It was branded to take different data type than the fMRIPrep input but in reality this only works for the specific examples and cannot generalize to other users/data.

There should be an easy version of ingression that does not require the whole package/building the docker image and that the researchers can easily modify to fit there data structure/processing instead of having the "input-type" argument.

[tsalo]

We're planning to move the ingression functions into a separate package, modeled after @smeisler's new https://github.com/PennLINC/ingress2qsirecon tool. However, it's important to remember that XCP-D is a BIDS App (i.e., a workflow designed to run on BIDS derivatives). We included other input types because either we (the PennLINC team) needed to process those particular data or our collaborators wanted a specific output supported. XCP-D is not meant to ingress an ever-expanding catalogue of non-BIDS-format preprocessed data.

I would instead recommend reorganizing any non-BIDS data into BIDS format outside of XCP-D and then testing XCP-D on that. Basically, try running your BIDSification step with another tool (you can just adapt our code if you want) and if there are elements in XCP-D that don't work with that (for example, there are some places in XCP-D where it includes special steps after ingression depending on the input type), then we can figure out how XCP-D could accomodate those data.

[cindyhfls]

btw do you think it is possible at all the skip the ingression and fit the required file name structure as a json file to the xcp-d input file names? This would be much more efficient in terms of time and space.

[tsalo]

In a perfect world, the different preprocessing pipelines would all output the same derivatives with different names. In practice, things need to be done to the data to make them ready for XCP-D. For example, we extract global signal, white matter, etc. from the preprocessed BOLD data from ABCD-BIDS and HCP-YA derivatives and put them in a confounds file with the motion parameters. If you have a preprocessing pipeline that produces the same outputs as fMRIPrep, but uses a different naming convention, you could apply a JSON like you propose and just make symlinks to the BIDS derivatives version of the derivatives.