I started with fmriprep, and used the --me-output-echos flag so the individual preprocessed echos would be output.
Then I ran tedana on those individual echos, and took the tedana ICA mixing tsv file, renamed the components classified as signal so they start with signal__.
Then I ran xcp_d using the -c flag and specifying the path to this file.
Now I am attempting to run FSL FEAT on the XCP_D output.
For the xcp_d output I noticed a few things, the sform and qform names are ‘Scanner Anat’ despite the image being in MNI152NLin6Asym_res-2 space. Also, the multiecho scan TR was 1.355s but is listed in the header as 1s in the xcp_d output. I manually changed the TR using fsledithd, and ignored the Scanner Anat after verifying the MNI152NLin6Asym_res-2 space brain overlayed the fsl MNI152_2mm brain.
However, when running the fsl feat step using the xcp_d output, I keep running into a fatal error during the preprocessing stage 2 step. I ran the step causing the error (/Users/julgr/fsl/bin/susan prefiltered_func_data_thresh 7.849772249999999 2.1231422505307855 3 1 1 mean_func 7.849772249999999 prefiltered_func_data_smooth
) in the terminal and got a Segmentation Fault: 11. FSL FEAT runs fine on the fmriprep output image that was used as input to xcp_d, but the fmriprep image doesn’t have the 36p motion correction or the ica components. So I thought perhaps it was because I was using fd-thresh to censor volumes and tried to run FSL FEAT on the image without the volume censoring in xcp_d but got the same error.
I noticed in the registration that the input is being interpreted very weirdly by fsl.
Could this be related to the Scanner Anat & TR issue in the header? Could the image be mislabeled or perhaps I am running xcp_d incorrectly? I initially ignored this since I thought prestats & stats were unrelated to the registration step and I was going to overwrite the associated registration files with the fmriprep ones anyway.
Any ideas for the FSL fatal error? Or a way to use fmriprep output while still taking into consideration the tedana ICA components? I am new to creating functional connectivity maps so any advice is appreciated!
I can’t offer much help here (not familiar with xcp_d, don’t use fmriprep) - but I will say that your image of “input being interpreted weirdly” looks like you are passing a demeaned image in as input - an image that has lost all of its anatomical detail/structure. My guess would be that xcp_d (a detrending/regression step?) is removing the mean plus everything else - this would give you nice timeseries, but the image itself would look like noise. Maybe the mean can be added back in for the processing steps.
Lately, I’ve started recommending that users orthogonalize their tedana noise components w.r.t. the signal components before running XCP-D, as nuisance regressors XCP-D uses (e.g., motion parameters) might capture variance that signal components also capture, which would mean retaining that variance if you orthogonalize the nuisance regressors w.r.t. the signal components. See Summary report of XCP-D using multi-echo BOLD and TEDANA for more info.
TL;DR: I’d recommend using --tedort in your XCP-D call and grabbing the noise components from that instead of labeling the signal components with signal__.
That’s very weird. I have no clue what could have caused that. If it persists in the most recent version of XCP-D, please let me know and I’ll open an issue. It’s probably a Nilearn issue though, since XCP-D uses Nilearn to create most of its images.
I fixed this in a recent version of XCP-D. Can you maybe try updating XCP-D and re-running your postprocessing?
Maybe your settings include too many regressors? Tedana ICA components + 36P + temporal filtering might be a problem.
I reran tedana using --tedort, then removed all accepted components from the mixing file tsv and used that as the custom confound file for XCP_D and got the resulting carpet plots:
I also wanted to let you know that I updated XCP_D to 0.6.3 and am still getting qform & sform name as Scanner Anat, despite the image being in MNI152NLin6Asym_res-2 space. As you said, the TR issue was fixed with this version.
I am able to run FEAT using just ‘Statistics’ instead of ‘Full-Analysis’ which I think is sufficient for what I am trying to do.
Thanks a lot for all of your suggestions, if you could let me know if the carpet plot looks ‘okay’ that would be great.
Just a note to my original post: To fix the poor registration, I was able to use the ‘Select Alternate reference image(s)’ option in the Pre-stats tab and choose the fmriprep output image in the same space instead. However, that did not fix the Error that I was getting during Preprocessing:Stage2. So, not helpful in my case as I would overwrite the registration anyway, but wanted to note in case others are coming across a similar issue and this is helpful.
