Field map error in fmriprep v24.0.0

michaelcohen · August 6, 2024, 8:45pm

Summary of what happened:

In fMRIprep, for two subjects out of a dataset of about 60 subjects, fMRIprep fails towards (I think) the end of the processing script. The output looks mostly reasonable despite the error message, except for two things that were true for both subjects: 1, There are subtle artifacts in the final data (in one case it’s just outside the brain mask, but in the other it is within the brain). 2, There seems to be a lack of alignment between the BOLD reference and the field map reference on the “Alignment between the anatomical reference of the fieldmap and the target EPI” stage of the output HTML. I’d like to figure out if there is a way to fix this issue, and if these data may be usable as-is. Note that we’re using a blip-up/blip-down PEPOLAR field map for these data.

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

srun singularity run \
--cleanenv \
-B /project/decety \
-B /scratch/midway3/jchen28 \
/project/decety/my_images/fmriprep-24.0.0.simg \
--participant_label=5004053 \
--fs-license-file="/project/decety/freesurfer_license.txt" \
-v -v \
--nthreads 8 \
--output-spaces MNI152NLin6Asym:res-2 \
--bold2anat-dof 6 \
--fd-spike-threshold 0.9 \
--dvars-spike-threshold 3 \
--skull-strip-template OASIS30ANTs \
-w /scratch/midway3/jchen28 \
/project/decety/VAD_BIDS \
/project/decety/VAD_BIDS/derivatives/fmriprep_v24 \
participant

Version:

24.0.0

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

Singularity

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

	1: [WARN] The recommended file /README is missing. See Section 03 (Modality agnostic files) of the BIDS specification. (code: 101 - README_FILE_MISSING)

	Please visit https://neurostars.org/search?q=README_FILE_MISSING for existing conversations about this issue.

	2: [WARN] The Authors field of dataset_description.json should contain an array of fields - with one author per field. This was triggered because there are no authors, which will make DOI registration from dataset metadata impossible. (code: 113 - NO_AUTHORS)

	Please visit https://neurostars.org/search?q=NO_AUTHORS for existing conversations about this issue.

        Summary:                   Available Tasks:        Available Modalities: 
        857 Files, 318.49GB                                MRI                   
        62 - Subjects                                                            
        1 - Session                                                              


	If you have any questions, please post on https://neurostars.org/tags/bids.

Relevant log outputs (up to 20 lines):

240801-13:36:05,95 nipype.workflow ERROR:
	 could not run node: fmriprep_24_0_wf.sub_5004053_wf.fmap_preproc_wf.fmap_reports_wf_auto_00000.fmap_rpt
240801-13:36:05,99 nipype.workflow INFO:
	 crashfile: /project/decety/VAD_BIDS/derivatives/fmriprep_v24/sub-5004053/log/20240801-115027_aa89766f-6adf-42d7-b550-7a4c4538308a/crash-20240801-115416-jchen28-fmap_rpt-5fa684b5-9739-48da-881d-bd8c613b4bbc.txt
240801-13:36:05,99 nipype.workflow INFO:
	 ***********************************
240801-13:36:05,155 nipype.workflow CRITICAL:
	 fMRIPrep failed: Traceback (most recent call last):
  File "/opt/conda/envs/fmriprep/lib/python3.11/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.11/site-packages/nipype/pipeline/engine/nodes.py", line 527, in run
    result = self._run_interface(execute=True)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/opt/conda/envs/fmriprep/lib/python3.11/site-packages/nipype/pipeline/engine/nodes.py", line 645, in _run_interface
    return self._run_command(execute)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/opt/conda/envs/fmriprep/lib/python3.11/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_rpt.

Traceback:
	Traceback (most recent call last):
	  File "/opt/conda/envs/fmriprep/lib/python3.11/site-packages/nipype/interfaces/base/core.py", line 398, in run
	    runtime = self._post_run_hook(runtime)
	              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
	  File "/opt/conda/envs/fmriprep/lib/python3.11/site-packages/nipype/interfaces/mixins/reporting.py", line 50, in _post_run_hook
	    self._generate_report()
	  File "/opt/conda/envs/fmriprep/lib/python3.11/site-packages/sdcflows/interfaces/reportlets.py", line 126, in _generate_report
	    plot_registration(
	  File "/opt/conda/envs/fmriprep/lib/python3.11/site-packages/sdcflows/viz/utils.py", line 87, in plot_registration
	    svg = extract_svg(display, compress=compress)
	          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
	  File "/opt/conda/envs/fmriprep/lib/python3.11/site-packages/niworkflows/viz/utils.py", line 140, in extract_svg
	    image_svg = svg2str(display_object, dpi)
	                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
	  File "/opt/conda/envs/fmriprep/lib/python3.11/site-packages/niworkflows/viz/utils.py", line 132, in svg2str
	    display_object.frame_axes.figure.savefig(
	  File "/opt/conda/envs/fmriprep/lib/python3.11/site-packages/matplotlib/figure.py", line 3390, in savefig
	    self.canvas.print_figure(fname, **kwargs)
	  File "/opt/conda/envs/fmriprep/lib/python3.11/site-packages/matplotlib/backend_bases.py", line 2193, in print_figure
	    result = print_method(
	             ^^^^^^^^^^^^^
	  File "/opt/conda/envs/fmriprep/lib/python3.11/site-packages/matplotlib/backend_bases.py", line 2043, in <lambda>
	    print_method = functools.wraps(meth)(lambda *args, **kwargs: meth(
	                                                                 ^^^^^
	  File "/opt/conda/envs/fmriprep/lib/python3.11/site-packages/matplotlib/backends/backend_svg.py", line 1339, in print_svg
	    self.figure.draw(renderer)
	  File "/opt/conda/envs/fmriprep/lib/python3.11/site-packages/matplotlib/artist.py", line 95, in draw_wrapper
	    result = draw(artist, renderer, *args, **kwargs)
	             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
	  File "/opt/conda/envs/fmriprep/lib/python3.11/site-packages/matplotlib/artist.py", line 72, in draw_wrapper
	    return draw(artist, renderer)
	           ^^^^^^^^^^^^^^^^^^^^^^
	  File "/opt/conda/envs/fmriprep/lib/python3.11/site-packages/matplotlib/figure.py", line 3143, in draw
	    artists = self._get_draw_artists(renderer)
	              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
	  File "/opt/conda/envs/fmriprep/lib/python3.11/site-packages/matplotlib/figure.py", line 231, in _get_draw_artists
	    ax.apply_aspect(locator(ax, renderer) if locator else None)
	                    ^^^^^^^^^^^^^^^^^^^^^
	  File "/opt/conda/envs/fmriprep/lib/python3.11/site-packages/nilearn/plotting/displays/_slicers.py", line 1579, in _locator
	    [[left_dict[axes], y0], [left_dict[axes] + width_dict[axes], y1]]
	      ~~~~~~~~~^^^^^^
	KeyError: <Axes: >

Screenshots / relevant information:

First affected subject:
fMRIprep output:

Preprocessed BOLD image (see black artifact at the front of the brain):

Second affected subject:
fMRIprep output

Preprocessed BOLD image (see dark line cutting through brain):

michaelcohen · August 14, 2024, 3:35pm

I just wanted to re-up this thread with a little bit more information and some additional concerns.

We found that these dark line-like distortions are happening on some subjects even when we don’t get an error message in fmriprep. The participants that show these distortions all seem to show a mismatch in the positioning of the brain on the " Alignment between the anatomical reference of the fieldmap and the target EPI" section. (That’s what I was trying to show in my original post, though I’m not sure if it was clear.)

It also seems that the same data processed in fmriprep v23.1.4 does not show these dark line-like distortions. The dark voxels show up as negative values in the raw preprocessed data from fmriprep v24.0.0 in fsleyes, while the same scan runs preprocessed in fmriprep v23.1.4 do not seem to have any negative values. (And in fact, should there ever be negative values in the preprocessed BOLD data?)

We had wanted to re-run our data through the updated fmriprep version in hopes of getting better field map results, but this makes me think there could be a major bug in fmriprep v24.0.0 that’s introducing this big artifact that would potentially distort our results. @effigies or other fmriprep developers, is this something that you guys have seen before?

effigies · August 14, 2024, 3:54pm

I have not seen it before. Do you see it with --ignore fmap-jacobian?

michaelcohen · August 15, 2024, 4:21pm

@effigies I tried re-running two of the subjects that had noticeable artifacts, and that does seem to clearly improve the output!

So now a few follow-up questions in seeing where to go from here:
– It does still appear from the HTML output that the two images in the " Alignment between the anatomical reference of the fieldmap and the target EPI" section are not well aligned. (In fact, they seem more shifted than with the standard v24 pipeline.) Is this a problem?

– Is this likely based on an oddity in our data, where we should just re-run all of the subjects using this ignore fmap-jacobian option? Or does this seem like a bug that you guys can fix in a new release of fmriprep?

– It seems like functional images processed in older versions of fmriprep consistently have 0 as the minimum intensity value. Images processed with fmriprep v24.0.0 do have some negative values, even when the visible artifact seems to go away with the ignore fmap-jacobian option. Is this to be expected, or should it be a cause for concern?

Thanks so much for your help with this!

michaelcohen · August 20, 2024, 3:29pm

I just wanted to post one more update on this: I took another look at the output using the ignore fmap-jacobian option. Although the actual data output doesn’t seem to have a visible artifact with this option, I took another look at the HTML output and that looks problematic. See the image below.

So I’m concerned that this doesn’t actually fix the issue, as there may be some sort of distortion that’s not visible? I’m going to also post this to Github, in case that’s helpful. For now, I think we’ll just revert to the older version of fmriprep that we had used (v23.1.4). But please let us know if there is more that we can try to get this version to work…

psadil · October 3, 2024, 1:42am

@michaelcohen This is a guess, but I’ve been exploring a possibly related issue that seems attributable to the poor coregistration that you’re noticing (as in, it’s not so much an issue with estimation or application of the fieldmap, but instead in the application of a fieldmap that has been taken out of register from the bold). The end is some pretty wild SDC exhibiting a range of artifacts (one example below).

For what it’s worth, a potential solution to the coregistration is in progress: Dilate fmap and epi masks before coregistration · Issue #461 · nipreps/sdcflows · GitHub (associated neurostars post Poor Fieldmap <-> Functional Registration in fMRIPrep (highly variable step)).

michaelcohen · October 3, 2024, 2:21pm

Thanks for making the link here – I agree, this does sound like it could be the same issue!

I’ll keep an eye out for the fix and can see if that helps with our dataset…

effigies · October 3, 2024, 5:22pm

This looks like Jacobians are applied to coreg references, even if --ignore fmap-jacobian is passed · Issue #3366 · nipreps/fmriprep · GitHub.

michaelcohen · October 4, 2024, 11:22pm

OK so one thing I’m confused about: if the raw data look OK (as far as I can tell) when using --ignore fmap-jacobian, but the HTML output looks weird, is the data actually OK? Or is there maybe still some artifact that I’m not able to catch by eyeball?

Also, if the underlying issue is a failure to align the fieldmap with the BOLD images, is the idea that the change you guys are making in the upcoming release, to dilate the mask, will fix this so that hopefully we don’t need to use --ignore fmap-jacobian to avoid artifacts being introduced?

Thanks,
Michael

psadil · October 7, 2024, 1:21pm

Good questions. This is only to indicate that I’m confused by the same points. The coregistration was one obvious failure point, but to me, it seems unclear whether there are others.

effigies · October 7, 2024, 1:38pm

It should be fine. If the light/dark patches affect the coregistration, it should be visible. If it’s not, then they didn’t damage the gray-white contrast to the point of mattering.

I don’t think so. I think there are plenty of cases with well-aligned fieldmaps that simply do not produce warps whose Jacobians are actually useful. We will leave the ability to reenable Jacobians, so you’re welcome to experiment.