Thank you for the reply @emdupre --much appreciated.
I’ll look forward to any helpful replies.
Kind regards.
Hi,
It’s unclear what files exactly you found and are trying to use, but a .txt file is not going to perform the warps needed to get you to the template space. We save the transform from T1w to template in the anat/ subdirectory, which should look something like:
sub-002/anat/sub-002_from-T1w_to-MNI152NLin6Asym_mode-image_xfm.h5
It looks like you’re also using a BOLD image that hasn’t been resampled in T1w space, so you’ll probably need to dig up the affine transform from BOLD to T1w, which should be in something like:
fmriprep_wf/
single_subject_002/
func_preproc_<...>/
bold_reg_wf/
bbreg_wf/
fsl2itk_fwd/
*.txt
You need to pass your transforms as a list, with the T1w-template first, and your BOLD-T1w second. If you are also using SDC, that should go third.
2 Likes
Hi @effigies,
Thank you for the reply.
I have the first two transforms you mentioned. I’ll hunt dow the SDC transform and also apply this.
Kind regards.
Hi @effigies,
Good news–I am able to transform my tedana-processed denoised epi to standard space using the t1_2_standard and bold_2_t1 transforms.
However, because I apply pepolar sdc, I would also like to apply this to my tedana-processed image. I can see that fmriprep uses the _warpfieldQwap_PLUS_WARP_fixhdr.nii.gz
However, opening this image just provide an empty image–just a rectangle with all ‘0’. Is this correct? Including this to my transform has no effect on the image. ie., no SDC correction applied.
Is this the correct transform file?
Kind regards
I’m not positive of the filename used, but you should be able to find it in the ApplyTransform transforms list, so if that’s what you’re seeing, then that’s probably right.
Are you sure that it’s all zeros? e.g.,
import nibabel as nb
img = nb.load(fname)
print("Zeros: ", np.allclose(img.get_fdata(), 0))
If so, I would inspect your input fieldmaps to make sure that they look sensible. All zeros suggests to me that you have the exact same data in your reverse-PE fieldmap, but this is just an intuition. I’m not as versed in the fieldmap components of the workflow as most of the rest.
Thanks for the quick reply @effigies
I used the Apply Transform to hunt down the correct transforms:
For SDC it is: single_subject_002_wf/func_preproc_ses_001_task_fmritask_echo_1_wf/sdc_wf/pepolar_unwarp_wf/cphdr_warp/_warpfieldQwarp_PLUS_WARP_fixhdr.nii.gz’
Using this file I return ‘False’ using the command you provided above.
I am using the following command for apply transform:
[‘antsApplyTransforms’, ‘–default-value’, ‘0’, ‘–input-image-type’, ‘3’, ‘–dimensionality’, ‘3’, ‘–float’, ‘1’, ‘–input’, ‘/home/fs0/gspitz/scratch/study/data/tedana_output/sub-002-ses-001/dn_ts_OC.nii’, ‘–interpolation’, ‘LanczosWindowedSinc’, ‘–output’, ‘/home/fs0/gspitz/scratch/study/data/fmriprep_output/fmriprep/sub-002/ses-001/func/sub-002_ses-001_task-fmritask_space-MNI152NLin6Asym_desc-dn_ts_OC_bold_test2.nii.gz’, ‘–reference-image’, ‘/home/fs0/gspitz/scratch/study/data/template/tpl-MNI152NLin6Asym_res-02_T1w.nii.gz’, ‘–transform’, ‘/home/fs0/gspitz/scratch/study/data/fmriprep_output/fmriprep/sub-002/anat/sub-002_from-T1w_to-MNI152NLin6Asym_mode-image_xfm.h5’, ‘–transform’, ‘/home/fs0/gspitz/scratch/study/data/fmriprep_output/fmriprep/sub-002/ses-001/func/sub-002_ses-001_task-fmritask_from-reference_to-T1w_mode-image_xfm.txt’, ‘–transform’, ‘/vols/Scratch/gspitz/study/data/fmriprep_output/fmriprep_wf/single_subject_002_wf/func_preproc_ses_001_task_fmritask_echo_1_wf/sdc_wf/pepolar_unwarp_wf/cphdr_warp/_warpfieldQwarp_PLUS_WARP_fixhdr.nii.gz’]
I have also inspected the phase-reverse epi for this participant. It looks sensible to me.
Kind regards,
Sorry, to be clear, are you saying that this is working for you? It sounds like your reverse-PE EPI looks good, you have a non-zero fieldmap estimate, and are able to apply the transforms. If you need further assistance, please clarify.
Hi,
Looking at the images again, I seem to be able to ‘recover’ to original preprocessed image from fmriprep. There are some differences, which I suspect are due to a different mask being applied in tedana. Ie., voxels are in same place in both images, but some voxels, o the outside of the brain are missing. Ie., looks like at some point tedana applies a tighter mask.
So it looks like things are working well.
Thank you for the help!
1 Like
Hi Taylor and @emdupre,
I was reading through this string as I have ME data and am currently preprocessing with fMRIPrep (thanks for all of your work on the pipeline!). I’m wondering - since this post was back in March '19 - how close is fMRIPrep with integrating multi-echo denoising? Just trying to figure out if it’s worth waiting until it’s integrated, or using fMRIPrep and tedana separately, but within the same pipeline as suggested here. Thanks so much for any thoughts and suggestions!
Best,
Nicole
2 Likes
Hi @NRob,
I was asking myself the same question and then stumbled onto the post below From April 2019. It seems that we will have to use fMRIPrep and tedana separately as they are no longer working to integrate them together.
“The choice to not incorporate tedana denoising into fMRIPrep was a conscious one. Given that fMRIPrep is geared towards robustness – and our lingering concerns as to whether tedana denoising was (yet) able to produce robust results – we decided not to include it for now.”
1 Like
Thanks for this. It does appear that putting tenana into the current workflow of fMRIPrep has been put on the back burner.
I’m still a bit confused about what fMRIPrep is actually currently doing with ME data:
- the --t2s-coreg option says that if this option is not enabled, ‘standard EPI-T1 coregistration in performed using the middle echo.’ There was a post back in Aug. 2018 where @emdupre says that "
--t2s-coregwould not combine the multiple echos. It’s another way to coregister the functional and anatomical data by first generating a T2* map and then coregistering the anatomical to that single image rather than to each of the echos separately."
There are posts in 2019 that talk about removing this option all together based on issues raised about this option, so I’m hesitant to use it.
So, if we don’t use this option, (2) the boiler plate says it “optimally combines” the ME data, and gives a reference to the Posse 1999 paper. Is this what fMRIPrep is doing with the ME data? What is outlined by Posse et al.?
Yes, I’d recommend against using --t2s-coreg at this time.
Optimal combination averages the data across echoes, with each voxel’s average weighted based on that voxel’s T2* value. The idea is to essentially predict what the data would be if you acquired each voxel its specific best echo time. In the tedana documentation, we have a walkthrough of optimal combination with figures that might be helpful.
1 Like
Thank you so much, @tsalo! I really appreciate the clarification about optimal combination, and the confirmation in not using --t2s-coreg. Thank you!
Hi Chris,
It seems that these paths have changed with new versions of fmriprep (I’m using 20.1.1) - could you point me toward where I can find the second transform in the fmriprep workdir?
McKenzie
Hello Gershon,
I know I am a little late to the party, but I have also wanted to combine tedana’s ME-ICA with fmriprep. I have a fix that has been working well for me.
I had to make the following changes to fmriprep:
Fmriprep container was build utilizing singularity’s --sandbox flag (1). This allows us to make edits to include tedana in the pipeline.
Edited the multi_echo interface to allow for tedana to be used instead of t2smap (2)
Removed skullstripping second pass step done before tedana (3)(a) (3)(b) since this was causing too much brain to be masked out. Created a custom_utils.py interface to replace skullstripping for this one step.
(1) singularity build --sandbox fmriprep_20.2.6 docker://nipreps/fmriprep:20.2.6
(2)edited file at fmriprep_ICA/usr/local/miniconda/lib/python3.7/site-packages/fmriprep/interfaces/multiecho.py to change ‘_cmd’ from ‘t2smap’ to ‘tedana’ and edit outputs in def _list_outputs(self)
(3)(a)To correct for this issue, we needed to find a way to remove the skullstrip_second_pass for only this one section. We want to interfere with the code as little as possible. I achieved this by creating a custom workflow in fmriprep_ICA/usr/local/miniconda/lib/python3.7/site-packages/fmriprep/workflows/bold/custom_utils.py` script can be found in attachments as ‘custom_utils.py’
(3)(b) After creating the custom_utils.py it had to be added into the main bold workflow fmriprep/workflows/bold/base.py at line 414
These changes have already been made in a version of fmriprep that I forked. They can be found here:
If you are interested in trying out, feel free to contact me!
Best,
Alex
2 Likes
Hello,
I’m helping out a collegue with multi-echo data and wanted to ask how does your workflow differ from running standard fmriprep (21.0.2) with the -me-output flag, getting native space single echo files and running tedana on those files?
We made these changes to the script before the --multi-echo flag was available. We are continuing to use it because it builds tedana directly into fmriprep. It’s very helpful to have everything in one singularity container and we can also utilize fmripreps qc outputs.
The improvement in dropout is quite significant using me-ica as opposed to the standard T2star method.
2 Likes
Hi @skebaas1,
Thanks so much for sharing details about this workaroud for integrating tedana into fmriprep! As I am about to analyze some ME-BOLD data, I was wondering if this is still the most up to date approach you would recommend (as you said, having the fmriprep QC is very valuable, so I’m leaning against separating the timeseries to different echoes and running tedana externally).
Many thanks,
Roey