N4BiasFieldCorrection error in sbref image

[heikestein]

Hi,

first of all, thank you for your great effort in standardizing preprocessing pipelines!
For now, I am trying to run a workflow with

• 2 bold series with MB factor 3 (bad contrast)
• 1 sbref series collected before run-01 for registration with T1 (high contrast)
• 1 T1w
• 1 phasediff+ 2 magnitude fmap images.

I am not quite sure why the workflow doesn't like my data - it fails on the bold_reference_wf.skullstrip_and_enhance_wf, specifically in the sbref N4 correction wf step. Error message below:

[Node] Error on "fmriprep_wf.single_subject_C19_wf.func_preproc_ses_01_task_wm_run_01_wf.bold_reference_wf.enhance_and_skullstrip_bold_wf.n4_correct" (/scratch/fmriprep_wf/single_subject_C19_wf/func_preproc_ses_01_task_wm_run_01_wf/bold_reference_wf/enhance_and_skullstrip_bold_wf/n4_correct)

RuntimeError: Command:
N4BiasFieldCorrection -d 3 --input-image /scratch/fmriprep_wf/single_subject_C19_wf/func_preproc_ses_01_task_wm_run_01_wf/bold_reference_wf/validate_ref/sub-C19_ses-01_task-wm_run-01_sbref_valid.nii.gz --mask-image /scratch/fmriprep_wf/single_subject_C19_wf/func_preproc_ses_01_task_wm_run_01_wf/bold_reference_wf/enhance_and_skullstrip_bold_wf/check_hdr/tpl-MNI152NLin2009cAsym_space-MNI_res-02_brainmask_trans_dil_hdr.nii.gz --output sub-C19_ses-01_task-wm_run-01_sbref_valid_corrected.nii.gz
Standard output:

Standard error:

Return code: 1

I am also not sure I conceptually understand what is failing here - my best guess that this is a problem of correcting the reference singleband before being registered the template?
Edit: I tried to run the pipeline without providing sbref images, and it looks like this way, bold images are N4 corrected and the workflow doesn't fail. However, direct registration of MB bold to MNI looks pretty imprecise.

I would appreciate any help, as I really want to promote your pipeline as a new standard in our lab :)

Btw, this is the exact command I ran:

docker run --rm -it -e DOCKER_VERSION_8395080871=18.09.0 -v /home/heike/Documents/Freesurfer/license.txt:/opt/freesurfer/license.txt:ro -v /home/heike/Desktop/MRI_ex:/data:ro -v /home/heike/Desktop/preproc_MRI_ex:/out -v /home/heike/Desktop/interm:/scratch poldracklab/fmriprep:1.2.5 /data /out participant --participant_label C19 -t wm --ignore slicetiming --bold2t1w-dof 6 --output-space template --no-submm-recon --fs-no-reconall --write-graph -v -w /scratch --template-resampling-grid native

[oesteban]

Hi @heikestein, if you could provide us with one subject that fails (shared privately) we could try to figure out what is the problem.

If there are some sharing concerns, maybe providing only one of the bold series (run-01 seems to be failing, that should be enough), and cropping it to the first 50 timepoints will make it useless for research objectives but more than enough to replicate the problem.

We are glad you like the software and are considering to make it the standard at your lab. I'll try to get back to you ASAP if you could provide me with some data.

[effigies]

@oesteban It sounds like it's failing on an sbref, not a bold image.

[oesteban]

I know, but I suspect this problem will uncover deeper problems in the workflow for when sbrefs are present. Having a failing dataset will speed up the process a lot (and that's also why I saved the due explanation of the issue for when I know exactly what is happening, I owe you that @heikestein ).

👍

[heikestein]

Hi Oscar, hi Chris,

thanks for getting back to me so quickly.
I shared an example participant in Dropbox, including all images that I fed in the pipeline myself when getting the error. Feel free to crop/use only one run for speeding up the process.
Note that I manually copied the run-01_sbref (acquired before run-01), and renamed the copy as run-02_sbref, as I think your pipeline didn't recognize the sbref otherwise (correct me if I'm wrong).

Thanks so much!

[heikestein]

Hi @oesteban, I wanted to check in on whether you had time to look at the bref preprocessing problem already. I am going to see our collaborators in Charité Berlin for the weekend to set up a larger study and preprocessing pipeline, and I wanted to propose them to use fMRIprep for preprocessing. Ideally, I wanted to show some results, as to convince them that this is the easiest way to handle our data. Any chance I can get the pipeline to work before that?

[effigies]

Hi @heikestein, I've reproduced your issue. I'm going to have a look at this now.

[effigies]

With verbosity turned on, here's the error:

Running N4 for 3-dimensional images.

Exception caught: 
itk::ExceptionObject (0x1c15180)
Location: "unknown" 
File: /tmp/ANTs/build/ITKv4-install/include/ITK-4.11/itkImageToImageFilter.hxx
Line: 250
Description: itk::ERROR: N4BiasFieldCorrectionImageFilter(0x1c02af0): Inputs do not occupy the same physical space! 
InputImage Origin: [-9.7541458e+01, 8.2441582e+01, -1.1816102e+01], InputImage_1 Origin: [-9.7414931e+01, 7.4311643e+01, -1.1493077e+01]
	Tolerance: 1.2000000e-05
InputImage Direction: 1.0000000e+00 0.0000000e+00 0.0000000e+00
0.0000000e+00 1.0000000e+00 0.0000000e+00
0.0000000e+00 0.0000000e+00 1.0000000e+00
, InputImage_1 Direction: 9.9938604e-01 3.4900175e-02 -3.0845155e-03
3.5034221e-02 -9.9638823e-01 7.7350509e-02
3.7382864e-04 7.7411083e-02 9.9699919e-01

	Tolerance: 1.0000000e-06

[oesteban]

The mask is not matching the sbref.

[oesteban]

Potentially related: nipreps/niworkflows#253

[effigies]

Don't think so:

$ % nib-ls /data/bids/heikestein/sub-C19/ses-01/func/sub-C19_ses-01_task-wm_run-0*.nii.gz
/data/bids/heikestein/sub-C19/ses-01/func/sub-C19_ses-01_task-wm_run-01_bold.nii.gz  int16 [ 64,  64,  39, 1215] 3.00x3.00x3.00x0.75   sform
/data/bids/heikestein/sub-C19/ses-01/func/sub-C19_ses-01_task-wm_run-01_sbref.nii.gz int16 [ 64,  64,  39,  10]  3.00x3.00x3.00x2.23   sform
/data/bids/heikestein/sub-C19/ses-01/func/sub-C19_ses-01_task-wm_run-02_bold.nii.gz  int16 [ 64,  64,  39, 1215] 3.00x3.00x3.00x0.75   sform
/data/bids/heikestein/sub-C19/ses-01/func/sub-C19_ses-01_task-wm_run-02_sbref.nii.gz int16 [ 64,  64,  39,  10]  3.00x3.00x3.00x2.23   sform

[effigies]

Though... it might be that there are 10 sbref volumes.

[effigies]

@heikestein I don't have time to test this until morning, probably, but if you just truncate your sbrefs to the first volume, that might do what you need. I was looking through the code and really having trouble identifying a difference between the estimated reference and the sbref, and the multiple volumes is all I could see.

[oesteban]

Though... it might be that there are 10 sbref volumes

Quite likely. Also important to check whether the qforms match. nib-ls found storms and thus they are reported, but ITK only reads the qforms.

…

On Thu, Jan 17, 2019, 16:21 Chris Markiewicz ***@***.*** wrote: @heikestein <https://github.com/heikestein> I don't have time to test this until morning, probably, but if you just truncate your sbrefs to the first volume, that might do what you need. I was looking through the code and really having trouble identifying a difference between the estimated reference and the sbref, and the multiple volumes is all I could see. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1463 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAkhxhujZcuUhoj6u0WNj2gY_FogX7lQks5vEROjgaJpZM4ZzbMr> .