Custom Template Error "unexpected fixed parameters"

Software Support
1

Summary of what happened:

Hi,

I have tried my luck using fmriprep with a custom template but unfortunately get an error relatively late in the processing pipeline, thrown by the “load_ants_h5” function (see below). In our case, we chose to create a group template from mean functional EPIs of our subjects.

Setting up the template worked ok with a little nasty workaround, which was to add the suffix _T1w.nii.gz to the template, instead of _bold.nii.gz (or similar), since fmriprep wouldn’t find the template otherwise.

The pipeline runs normally for quite a while until I get the error pasted below, together with the message that the preprocessing steps couldn’t be finished. I really don’t know how to interpret / where the issue lies, so I’d appreciate any input :slight_smile:

Command used (and if a helper script was used, a link to the helper script or the command generated):

snipped from bash script:

singularity run --cleanenv --bind /home $FMRIPREP_SING_DIR \
$BIDS_DIR $DERIVATIVES_DIR \
participant \
-w $WORKING_DIR \
--participant-label $SUBJECTS \
--ignore slicetiming \
--omp-nthreads 8 \
--nthreads 12 \
--mem-mb 30000 \
--output-spaces CUSTOMTGA:res-150 \
--fs-license-file $LICENSE_FILE \
--fs-no-reconall \
--longitudinal \
--skip-bids-validation \
--write-graph \
--stop-on-first-crash

Version:

  • fMRIPrep version: 23.2.1

Environment (Docker, Singularity / Apptainer, custom installation):

Singularity, executed by bash script

Data formatted according to a validatable standard? Please provide the output of the validator:

Data according to BIDS standard, no errors

Relevant log outputs (up to 20 lines):

Node Name: fmriprep_23_2_wf.sub_13_wf.bold_ses_A_task_sequenceviolation_dir_ap_run_01_wf.bold_std_wf.fmap_recon
File: /home/work/luisa/TGA/BIDS_FUNC_SPACE/derivatives_custom/sub-13/log/20240518-161413_a2582651-f4e3-4484-84fd-8503b4113039/crash-20240518-210625-fmriprep-fmap_recon.a0-81dbd89a-a636-420d-a34c-bb253a75c22e.txt
Working Directory: /home/work/luisa/TGA/tmp/fmriprep_tmp/fmriprep_23_2_wf/sub_13_wf/bold_ses_A_task_sequenceviolation_dir_ap_run_01_wf/bold_std_wf/_in_tuple_CUSTOMTGA.res150/fmap_recon
Inputs:
fmap_ref_file:
in_coeffs:
inverse: [False]
target_ref_file:
transforms:
Traceback (most recent call last):
  File "/opt/conda/envs/fmriprep/lib/python3.10/site-packages/nipype/pipeline/plugins/multiproc.py", line 67, in run_node
    result["result"] = node.run(updatehash=updatehash)
  File "/opt/conda/envs/fmriprep/lib/python3.10/site-packages/nipype/pipeline/engine/nodes.py", line 527, in run
    result = self._run_interface(execute=True)
  File "/opt/conda/envs/fmriprep/lib/python3.10/site-packages/nipype/pipeline/engine/nodes.py", line 645, in _run_interface
    return self._run_command(execute)
  File "/opt/conda/envs/fmriprep/lib/python3.10/site-packages/nipype/pipeline/engine/nodes.py", line 771, in _run_command
    raise NodeExecutionError(msg)
nipype.pipeline.engine.nodes.NodeExecutionError: Exception raised while executing Node fmap_recon.

Traceback:
	Traceback (most recent call last):
	  File "/opt/conda/envs/fmriprep/lib/python3.10/site-packages/nipype/interfaces/base/core.py", line 397, in run
	    runtime = self._run_interface(runtime)
	  File "/opt/conda/envs/fmriprep/lib/python3.10/site-packages/fmriprep/interfaces/resampling.py", line 169, in _run_interface
	    transforms = load_transforms(self.inputs.transforms, self.inputs.inverse)
	  File "/opt/conda/envs/fmriprep/lib/python3.10/site-packages/fmriprep/utils/transforms.py", line 26, in load_transforms
	    xfm = load_ants_h5(path)
	  File "/opt/conda/envs/fmriprep/lib/python3.10/site-packages/fmriprep/utils/transforms.py", line 85, in load_ants_h5
	    raise ValueError(msg)
	ValueError: Unexpected fixed parameters
	Expected: [193. 229. 193.  96. 132. -78.   1.   1.   1.  -1.   0.   0.   0.  -1.
	   0.   0.   0.   1.]
	Found: [ 1.60000000e+02  1.60000000e+02  9.00000000e+01 -1.01934868e+02
	  9.70576706e+01 -9.59674072e+00  1.24999988e+00  1.25000012e+00
	  1.25000000e+00  9.96969665e-01 -1.56333234e-08  7.77913035e-02
	  2.38553837e-02 -9.51819457e-01 -3.05729676e-01 -7.40432784e-02
	 -3.06658965e-01  9.48935129e-01]

Screenshots / relevant information:

2

Hi @luisa_sophia,

Why did you choose that? I don’t think spatial normalization (which uses the T1w image) will go well if trying to register to a BOLD image.

Also, in future posts I would fill out as much of the Software Support template (which I added back in for you) as you can.

Best,
Steven

3

Hi @Steven, we chose to normalize into a template created from BOLD images to minimize co-registration problems from functional to T1w space (for an example of using this method, see Navarro et al. 2015 Functional topography of the human entorhinal cortex).

I kind of assumed that one could theoretically also specify template-spaces from modalities other than T1w in fmriprep, but maybe I am wrong here :slight_smile: But thinking about it, the better solution will probably be to stay in subject specific functional space for the pre-processing, and warp my results post hoc into our custom template.

And thank you for the tip, will definitely take care of filling out the Software Support template next time!

Best,
Luisa

4

Hi @luisa_sophia,

The functional-to-T1w registration mainly happens in subject space, and them this transform is combined with the subject T1w-to-template T1w space registration to get the BOLD to the final template space.

By using a BOLD image as a template space, you will have a hard time calculating the subject T1w-to-template T1w registration. Image registration works best when the two images being registered have the same contrast (BOLD is also very noisy in general).

You could just make a mean T1w from your study population, or use MNI. You should try to have fmriprep calculate the registrations since it will perform all the transforms in a single step, which minimizes data interpolation.

Best,
Steven

5

Hi @luisa_sophia,

I also noticed now that you provided your command that you added --fs-no-reconall which is not recommended. The boundary based registration afforded by using FreeSurfer outputs allows for better BOLD-to-T1w coregistration. I would recommend removing that flag when you rerun participants.

Best,
Steven

6

You definitely have a point that it is most efficient in minimizing interpolation to have fmriprep normalise to the desired template space already during pre-processing.
But just for my understanding: if we stick for a minute with the idea to completely stay in BOLD space by using a BOLD template (of course knowing that this comes with a big tradeoff: resolution). There currently is not really a way to do this with fmriprep, right?

Fmriprep allows specifying --output-spaces func (alongside --output-spaces anat), as subject-specific template space, which skips normalisation to anatomical for the functional runs. Or, at least this is what I got from the output files - correct me if I am mistaken!
Based on this I thought that it could be possible to have fmriprep normalise to a generic functional space (not subject space) as specified by a functional template. However, I understand that this is not the “usual” way, and that the main goal of allowing the specification of custom templates was to allow normalisation to other anatomical templates.

thanks, but the flag was put intentionally, as running surface preprocessing drastically increased runtime, and we encountered errors more frequently. However, this experience was based on older fmriprep versions, so the second point might have been resolved in the current version.
But it is really important to reconsider decisions again, so it might be worth giving it a shot again. :slight_smile:

Anyways, thank you so much for taking the time!

Best,
Luisa

7

Hi @luisa_sophia

You can stay in BOLD space by specifying func or bold in an output space. That will keep everything in their native space and resolution. So not the same as a BOLD template. I’m still not sure if I see the value in trying to register to a BOLD group template image as opposed to a T1w group template.

I go by the philosophy that it’s better to spend a lot of time doing things right the first time rather than having to reprocess later on due to errors on trying to cut corners :slight_smile:

Best,
Steven