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> .

[heikestein]

@effigies @oesteban thanks, great!
If it was due to the number of volumes for the sbref, that would be an easy fix. I will try and run the pipeline today and let you know as soon as it's done!

[heikestein]

Hi, I ran the pipeline yesterday evening and it ran without problems, great! I have to inspect the results now, but the n4 problem is gone in any case.

[effigies]

Excellent! Thanks for the update. Out of curiosity, do you know the reason that 10 sbref volumes were collected, and the protocol? Assuming that they were just 10 continuously acquired images, the later images probably have lower contrast than the first one or two.

I'm asking so we can figure out the best way to handle these situations. If there's a good reason to want to use >1 volume, then we should figure out how to use them. Otherwise we can either truncate to the first volume ourselves or produce an informative warning/error when >1 volume is present.

[heikestein]

Hi @effigies, sorry for the late reply!
There was no specific reason to acquire 10 scans. I read about the advantages of collecting a sbref for MB sequences in a forum and asked our technician to set up the sequence, but experience with MB sequences at our center at that time was near zero, so it was an arbitrary decision (in fact, we have several subjects without sbref scans from that session, would you recommend using a different session's sbref in that case, although the subject's position will be quite displaced for bold and sbref in that case?).
It might be that averaging across 10 images made the reference more stable to register to, I could imagine, but that's just speculation. I feel perfectly happy with just cropping the series to the first image, seeing this works perfectly.

[oesteban]

Added an issue to remind us of this problem. I'll leave the title there to keep findability if users run into this very same bug.