tsalo
commented
2 days ago 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.
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.