edickie / ciftify

The tools of the Human Connectome Project (HCP) adapted for working with non-HCP datasets
https://edickie.github.io/ciftify/
MIT License
111 stars 156 forks source link

Trouble with fmriprep_ciftify_BIDS-app #139

Open StephDocTUM opened 4 years ago

StephDocTUM commented 4 years ago

I am running the following command:

docker run -ti --rm \ -v /Users/neurolab/Desktop/Test_sub_002_fcmriprep_ciftify:/data:ro \ -v /Users/neurolab/Desktop/Test_sub_002_fcmriprep_ciftify:/out \ tigrlab/fmriprep_ciftify:1.1.8-2.1.1 \ /data /out/out participant

And receive the following message:

/usr/local/miniconda/lib/python3.6/site-packages/bids/grabbids/init.py:6: FutureWarning: grabbids has been renamed to layout in version 0.6.5, and will be removed in version 0.8 warnings.warn("grabbids has been renamed to layout in version 0.6.5, and will be removed in version 0.8", FutureWarning) cmd: bids-validator /data Failed with returncode 1

But it continues to run. The Data is BIDS valid.

What does that mean?

And can I run fmriprep_ciftify and tell it where to find the already executed recon-all folder?

Best

edickie commented 4 years ago

It looks like you might be mounting /Users/neurolab/Desktop/Test_sub_002_fcmriprep_ciftify to both /data and /out? This might be causing issues? Try mounting two different folders to /data and /out?

The /data folder needs to contain the bids validated inputs. (i.e. /data/sub-...)

Also, if the recon-all outputs are in the output folder (i.e. /out/freesurfer/sub-/..) ciftify should find work from them.

One way to check is to run the command with the "--debug --dry-run" flags. These will cause the bids-app to print all the steps fmriprep-ciftify would run to the terminal instead of running them. You can use this to get a better idea of what is happening.

StephDocTUM commented 4 years ago

I am doing now fmriprep and ciftify separately and that works fine. So thats okay.

But it seems to register my BOLD signal far up too cranial. Any ideas why?

Best,

PialRegCor PialRegSag SAL_conn

DAN_conn DMN_conn fmri_DV fmri_LM fmri_Subcortical PialRegAx

StephDocTUM commented 4 years ago

That is the BOLD-Signal after ciftify_recon_all and ciftify_subject_fmri (and with fmriprep already done). That looks distorted.

Bildschirmfoto 2020-06-09 um 17 27 54

And here the one only after fmriprep which looks okay.

Bildschirmfoto 2020-06-09 um 17 30 02
edickie commented 4 years ago

Yes, something definitely went wrong there.

One question - is your T1w higher resolution (i.e. voxel size less than 1x1x1mm)? I have noticed one bug where the header from the higher-res freesurfer pipeline outputs is not read properly - which causes big problems with the registration steps inside ciftify (like this one).

A way to check is to run fmriprep with the --no-submm-recon option and see if that fixes the problem.

StephDocTUM commented 4 years ago

Thanks a lot for the reply. It is 1.2x1.2x1.2mm (GSP-Dataset)

I ran the pipeline with your suggested command and thats the result:

DAN_conn DMN_conn fmri_DV fmri_LM fmri_Subcortical PialRegAx PialRegCor PialRegSag SAL_conn

It still does not look correct.

So thats what I'm doing:

1.) recon-all

2.)fmri: fmriprep-docker /Users/neurolab/Desktop/Test_GSP_final /Users/neurolab/Desktop/Test_GSP_final/derivatives/participant --participant-label 21 --fs-license-file /Users/neurolab/Desktop/Stephan/Programmes/freesurfer/license.txt --fs-subjects-dir /Users/neurolab/Desktop/Test_GSP_final/derivatives/freesurfer/sub-21 --no-submm-recon

3.) ciftify_recon_all --ciftify-work-dir /Users/neurolab/Desktop/Test_GSP_final_ciftify/ciftify_anat --fs-subjects-dir /Users/neurolab/Desktop/Test_GSP_final/derivatives/freesurfer sub-21

4.)ciftify_subject_fmri --ciftify-work-dir /Users/neurolab/Desktop/Test_GSP_final_ciftify/ciftify_anat /Users/neurolab/Desktop/Test_GSP_final/derivatives/participant/fmriprep/sub-21/ses-1/func/sub-21_ses-1_task-rest_run-1_space-MNI152NLin2009cAsym_desc-preproc_bold.nii.gz sub-21 ses-1_task-rest

StephDocTUM commented 4 years ago

I tried now do to ciftify_subject_fmri with --FLIRT-to-T1w and these are the results:

fmri_DV fmri_LM fmri_Subcortical PialRegAx) PialRegCor PialRegSag SAL_conn DAN_conn DMN_conn

It seems to be that fmriprep did not register the T1w to my func images right?

Is there a better solution to register T1w with the func images instead of using flirt?

Best,

edickie commented 4 years ago

The last version --FLIRT-to-T1w does look a lot better.. The good news is that the versions of ciftify above 2.2.0 use boundary-based registration (BBR) when running --FLIRT-to-T1w using a white matter mask derived from the freesurfer outputs - which actually tends to work as well the BBR registration in fmriprep. So you might be good from here?

Are you taking the space-T1w outputs from fmriprep? Those would be the only one's that are registered to the T1w image (that ciftify would pull from) you may need to run rerun fmriprep with the --output-spaces T1w flag to get those.

StephDocTUM commented 4 years ago

Ok, I will have at --output-spaces T1w: That registers to my individual T1w but actually I want my anat T1w and func of all my subjects registered to the template otherwise I cannot compare them?

For some projects I am interested in analysis in the volume space not surface. This would be that output: .nii.gz # the MNI transformed func.nii.gz ? How is that output registered? The different subjects .nii.gz seem not to be registered to a same template?

Is the method ciftify_vol_result helpful for preprocessing the volume data to cifti volume space?

Are there any advantages between the ciftify volume func output to the fmriprep volume func?