Fmriprep 1.0.6-2 issues: semi-random brain mask failure and super bright areas in epi

1

Hi,
I’m getting some puzzling outputs of the brain mask for some (but not other) functional data, some weird “brightness” and issues with the report with the new 1.0.6 version. They might (hopefully) be all related.

Here is the history of the puzzle and what I did to try to get at it so far. Help in where to look next and what to check is appreciated!

Originally I ran some anatomical and resting state data with fmriprep version 1.0.0.rc6 from the singularity container (poldracklab_fmriprep_1.0.0-rc6-2017-10-11-cb35f5c22c6a.img). All fine.

usr/local/miniconda/bin/fmriprep /project/source/ /project/derivatives/ participant --participant-label subjx --ignore slicetiming --ignore fieldmaps --ignore-aroma-denoising-errors --output-space T1w --no-freesurfer --work-dir /project/work

Then I wanted to update all my data to the newer version of fmriprep 1.0.6-2 (poldracklab_fmriprep_1.0.6-2-2018-01-30-dc6144d544ef.img) and field maps) . Same input data otherwise.

/usr/local/miniconda/bin/fmriprep /project/source/ /project/derivatives/ participant --participant-label subjx --ignore slicetiming --ignore-aroma-denoising-errors --output-space T1w --fs-no-reconall --work-dir /project/work --fs-license-file /data/dorit/license.txt

The output report showed

  1. some chunks in the brain mask is missing for half of the runs (2 sessions a 4 runs),
  2. very bright areas in the frontal areas for all runs and
  3. when I try to open the report.htm file locally (working on HPC cluster) no images are shown (which is resolved by downloading the figure folder putting it in a subject-labled folder in the same directory. Maybe 3 is intended and I just missed that part in the docs.)

About 1 and 2:
I was puzzled (given that the output and reports looked normal in the older fmriprep version).
So I ran the same command, just without field maps. No change, ie. same issue 1 and 2.

Then I ran the same command, without field maps and without one of the originally affected runs (run1) (just to test if its is run dependent or some random thing). And I get different runs now affected by 1 (only 2 our of the remaining 7), as well as remaining issue 2 for all runs. In addition it ran slice time correction although I specified it shouldn’t.

/usr/local/miniconda/bin/fmriprep /project/source/ /project/derivatives/ participant --participant-label subjx --ignore slicetiming --ignore fieldmaps --ignore-aroma-denoising-errors --output-space T1w --fs-no-reconall --work-dir /project/work --fs-license-file /data/dorit/license.txt

“Slice timing correction: Applied”

I also reran the older fmriprep version again to make sure I’m running it on the same data. Again the old version does not produce issues 1-3 on the same source data.

I should mention that I did always delete/move the output directory and the working directory from that subject. The input nii data in the source folder looks fine at first glance (i.e. not crazy movements or brightness to begin with).
No html report reports any actual errors (nor any string searches in the log files).

Any idea where this might be getting off track? Maybe I’ just missing something obvious, but I don’t know what yet. Help appreciated!

Thanks!

PS
Apologies for the long post. Just trying to be informative. For visualization purposed I uploaded screenshots form the epi2T1 registration onto dropbox. Let me know if there is a better way to share the images. https://www.dropbox.com/sh/4ucl7u1nv3jq605/AAB1_Iku0ERu3RHH8Ox63ro4a?dl=0
Notice that the brain is quite ‘special’, i.e. huge ventricles and no CC.

2

Seems like a regression caused by our recent attempts to improve the quality of the BOLD masks. The slic timing issue is misterious. Could you share a) the full execution log (console output) b) reports (HTML files and folders with svg images)?

Could you try running it with --ignore fieldmaps slicetiming instead of two --ignore? This should help with the slice timing issue.

3

Sure thing!

What’s the best way to share?

4

dropbox should do, just zip everything up

5

Its up in the same link!

I gave the last test described (i.e. 7 runs, without fieldmaps).

I will rerun the case with all runs --ignore fieldmaps slicetiming and upload those files as well if its helpful! Thanks for looking into it!

6

Thanks this is very useful. It seems that the BOLD brainmasks was estimated correctly (judging from the ROIs reportlets). The BOLD/T1w coregistration also looks ok, but indeed the BOLD volumes in those reportlets look weird. I wonder if this is just a vizualization issue. Could you open the BOLD brainmask nifti files and check if the look ok?

7

I should have mentioned!
The brainmask nii file look like the EPI-T1 registration issue (not like the brainmask in the compcorr outline figure… (uploaded nii to same dropbox, fetch automaticlaly unzipped the image hence the different filename, but its …ses-1_task-rest_run-03_bold_space-T1w_brainamask.nii.gz)

8

I see. Sorry for that. We can look deeper into this if you could share the raw data with us (a single problematic EPI should suffice to start with).

9

I opened two issues based on your reports: https://github.com/poldracklab/fmriprep/issues/964 and https://github.com/poldracklab/fmriprep/issues/963

Let us know if you still have issues with suppressing slicetiming correction.

10

BTW could you also try to run this with FreeSurfer?

11

thanks for getting at it!

@slicetiming: ran it with “–ignore fieldmaps slicetiming” and not applied this time. I’ll keep having an extra eye on it for future subjects.
@freesurfer: The midline pial estimation and parcellation is not satisfactory because of the agenisis of the corpus callosum, so we’re running it outside of fmriprep and have not fed it back into it (probably wouldnt’ because we’re trying to stay in subject space, given the large ventricles).
If you just want to see if it improves the skullstripping, happy to run it and see what happens.

I can send an EPI run over. Do you have a direct upload option?

12

Maybe you can upload the minimal dataset on http://OpenNeuro.org and share it with krzysztof.gorgolewski@gmail.com

13

Done.

You still think its useful to run with FS?

14

Hi @dorit, I don’t think it is necessary to run FS (https://github.com/poldracklab/fmriprep/issues/963#issuecomment-364252548)

15

@oesteban ok thanks!

16

@dorit: one minor check. Could you please see if the data type of the original functional series is int16?

e.g. (using nibabel)

$ nib-ls myfile.nii.gz 
myfile.nii.gz uint16 [ 64,  64,  48, 484] 3.00x3.00x3.00x0.00   sform

This example would confirm that this image is uint16.

17

Having never used nibabel directly I made it up to this output (following http://nipy.org/nibabel/gettingstarted.html) , which is I think what you wanted to know?

img.get_data_dtype() == np.dtype(np.int16)
True

here “img” is the nifti file from the run that prodced the funky output.

18

just checking in about this.
I saw you guys jumped right at it and already closed one issue a couple of days ago (awesome).
I’m trying to decide whether to move forward with an older version of fmriprep or wait for the new release. Any input you can give on the timeline here?

19

We are working to release ASAP. In fact, I’d like to release today.

I would totally recommend waiting for that new release as it should fix your issue (I looked through 2000 masks to make sure it does…). Any feedback on this new release will be very very much appreciated.

20

sure thing! I’m more than happy to test it!