So my alternative is to use the nipype version of ICA-AROMA, but I am not sure how to do this using fmriprepped data. Ideally, I would like to maintain the 1st pass registration to child MNI space so could I use the data in this space as inputs for ICA-AROMA or should I be using data in native space? Then, in order to satisfy the other inputs could I just run a 2nd pass registration to adult MNI space using FSL FLIRT and FNIRT?
This is not possible. ICA-AROMA only works in the MNI152NLin6Asym (aka FSL’s MNI152 template) and denoised timeseries are only generated in that space.
Following up there, but please note that the errors you are experiencing are unrelated to ICA-AROMA.
That’s actually exactly the same as letting fMRIPrep do the job. Unless you modify the code base of AROMA (https://github.com/maartenmennes/ICA-AROMA) to run on a new template, you are better off using the default fMRIPrep implementation.
In your case, maybe a more elaborate denoising strategy similar to ICA-AROMA but customized to your pediatric cohort (i.e. the pediatric template) would be better. You can implement such a strategy with FSL FIX, for instance.
Thanks again @oesteban for your technical support and suggestions.
Not sure why the error occured, but I have now run 3 subjects with ICA-AROMA with no errors, and subject 004 ran fine without AROMA - I will test them again with the --use-aroma flag.
One thing that persists, is the output of denoised timeseries in all templates:
Are these all actually now in MNI152NLin6Asym space?
Since the desc-smoothAROMAnoaggr is originally calculated in MNI152NLin6Asym space, that one should be fine for sure.
Then, about the other two, I can’t recall on top of my head whether the transform from MNI152NLin6Asym to them is being applied. It seems quite unlikely because to do so we would need to concatenate transforms back to T1w space and then forward to each of these template spaces. If we are not doing that, then these extra spaces should not be used and I’ll take care of fixing that. I’ll double check and get back to you.
Nope, you are safe. The fact that syn-sdc brings prior information from the 2009c space doesn’t mean that correction happens in that space. It indeed happens in the original native space of your bold run.
However, before you do that, I’d really think about whether you want to use the smoothAROMAnonaggr output or alternatively the preproc one and use the AROMA timeseries to regress out noise. If you did that, you are probably better off using the 2009c MNI.
EDIT: Please delete the sub-0001_task-rest_run-01_space-MNI152NLin2009cAsym_desc-smoothAROMAnonaggr_bold.nii.gz in any of the cases.