Noisy intermediate bold reference image

Summary of what happened:

We ran fmriprep successfully, on a dataset with a T1, task data, and single band reference images. The subject’s sbrefs look fine in the initial form (in bids/[subj]/func/), but the intermediate image in bids/derivatives/fmriprep/[subj]/func (named with suffix boldref) is essentially all noise. Then the boldref image in standard MNI space looks OK again (see attached image).

Relatedly (I assume), the brain mask shown in the susceptibility distortion correction part of the QC report is messed up, missing the posterior third of the brain (see attached image).

I’m trying to trace back where the problem originates, and am having trouble finding all the commands, and the order in which they’re run. Is there a place where fmriprep stores a log of the actual commands, and not just the workflows? I see “command.txt” files in some, but not all the *_wf folders. If the command.txt file doesn’t exist, does that mean no commands were run, or is there another place where the command is saved? I would just like to reproduce the problem in as minimal a way as possible (not run fmriprep again).

Aside from that, does anyone know what might cause this problem and how to fix it? Other runs from the same session were fine, so maybe it’s just motion, but I know it’s not something inherent to the scan session.
From digging around it seems that the initial affine transform (calculated by antsAI) in func_preproc_task_[taskname]_wf/final_boldref_wf/enhance_and_skullstrip_bold_wf/init_aff might be the culprit, but I’m also seeing this comment in the fmriprep documentation on the bold_reg_wf:
"

After either BBR workflow is run, the resulting affine transform will be compared to the initial transform found by FLIRT. Excessive deviation will result in rejecting the BBR refinement and accepting the original, affine registration.

"
I thought this may explain why the final boldref image in standard space is ok (because it rejected the bad affine transform?) but I couldn’t find where to check whether the BBR refinement was accepted or rejected.

Command used:

docker run --rm -it -v bulk:bulk \
-v scratch:scratch \
-v /usr/global/freesurfer:/usr/global/freesurfer \
nipreps/fmriprep:23.0.2 \
bulk/study/bids \
bulk/study/bids/derivatives/fmriprep \
participant \
-w scratch/study_fmriprep/subj1 \
--participant-label subj1 \
--nprocs 8 \
--random-seed 2312 \
--skull-strip-t1w force \
--force-bbr \
--slice-time-ref 0 \
--fs-subjects-dir bulk/study/bids/derivatives/freesurfer \
--fs-license-file /usr/global/freesurfer/6.0.0/license.txt \
--write-graph --verbose

Version & Environment:

Running fmriprep 23.0.2 on Docker

Screenshots / relevant information:


Hi @dani and welcome to neurostars!

Do you get similar results with the most current stable release (23.2.0 at this time)?

Best,
Steven

1 Like

This looks a bit like:

Hopefully it’s resolved in the latest release.

1 Like

Thanks so much guys for the very quick response! I’ll rerun using the most recent release and see if that helps.

I’ve tried to rerun this with version 23.2.0, but now I’m getting an error that “Sophisticated PEPOLAR schemes are unsupported.” I see this error reported already elsewhere (Sophisticated PEPOLAR schemes are unsupported · Issue #2667 · nipreps/fmriprep · GitHub) but was that issue not resolved in a previous version? I don’t think I changed anything else in my processing setup from version 23.0.2.

Hi @dani,

Can you describe your fmap acquisition and pairings with BOLD images? This error might arise because you’ve mapped more than one phasediff or multiple epis of the same phase encoding direction accidentally. Some of your fmap jsons (and BOLD jsons if you are using the b0fieldidentifier method) would be helpful.

Best,
Steven

Did something about handling the fieldmaps change between versions 23.0.2 and 23.2.0 though? I’m just curious since I didn’t get any errors for the older version.
But anyway, yes, it does appear that two EPIs of the same phase encoding direction are mapped to the first two task scans each, so I’ll rerun after we fix that. The relevant scans are:

  1. fmap1 PA (paired with runs 5 and 6 - task 1 conditions 1 and 2)
  2. fmap1 AP (paired with runs 5 and 6 - task 1 conditions 1 and 2)
  3. fmap2 PA (paired with runs 5 and 6 - task 1 conditions 1 and 2)
  4. fmap2 AP (paired with runs 5 and 6 - task 1 conditions 1 and 2)
  5. Task 1 condition 1 (preceded by sbref image)
  6. Task 1 condition 2 (preceded by sbref image)

I don’t believe we are using the B0FieldIdentifier method, although now that I’m looking more closely, I do see that field in the json files in the derivatives folder, although the field was not included in the initial json files (we just had an “IntendedFor” field in those).
I can’t seem to attach the whole json files, but I’ll just paste the relevant parts of it below:

bids/subjID folder (“subjID_acq-Neut_dir-PA_run-01_epi”):

{
    "Modality": "MR",
    "MagneticFieldStrength": 3,
    "ImagingFrequency": 123.25,
    "Manufacturer": "Siemens",
    "ManufacturersModelName": "MAGNETOM Prisma Fit",
    "InstitutionName": "Biomedical Research",
    "InstitutionAddress": "address",
    "DeviceSerialNumber": "67096",
    "StationName": "MRC67096",
    "BodyPartExamined": "BRAIN",
    "PatientPosition": "HFS",
    "ProcedureStepDescription": "Study",
    "SoftwareVersions": "syngo MR XA30",
    "MRAcquisitionType": "2D",
    "SeriesDescription": "ABCD-fMRI_FM_PA_EM01",
    "ProtocolName": "ABCD-fMRI_FM_PA_EM01",
    "ScanningSequence": "EP",
    "SequenceVariant": "SK",
    "ScanOptions": "FS",
    "PulseSequenceName": "epse2d1_90",
    "ImageType": [
        "ORIGINAL",
        "PRIMARY",
        "FMRI",
        "NONE"
    ],
    "ImageTypeText": [
        "ORIGINAL",
        "PRIMARY",
        "M",
        "ND"
    ],
    "NonlinearGradientCorrection": false,
    "SeriesNumber": 6,
    "AcquisitionTime": "17:23:28.345000",
    "AcquisitionNumber": 1,
    "ImageComments": "SENSE1",
    "SliceThickness": 2.4,
    "SpacingBetweenSlices": 2.4,
    "EchoTime": 0.08,
    "RepetitionTime": 7.033,
    "MTState": false,
    "FlipAngle": 90,
    "PartialFourier": 1,
    "BaseResolution": 90,
    "ShimSetting": [
        565,
        -11496,
        -6167,
        492,
        42,
        149,
        143,
        -17
    ],
    "TxRefAmp": 237.075,
    "PhaseResolution": 1,
    "VendorReportedEchoSpacing": 0.00051,
    "ReceiveCoilName": "Head_32",
    "ReceiveCoilActiveElements": "HEA;HEP",
    "CoilString": "Head_32",
    "PulseSequenceDetails": "%CustomerSeq%\\cmrr_mbep2d_se",
    "WipMemBlock": "f889314f-0b92-4106-a46e-cd1c350ca2ad||Sequence: R017 nxva30a/master r/e4e260217; Mar 27 2023 20:12:45 by eja",
    "CoilCombinationMethod": "Sum of Squares",
    "MatrixCoilMode": "SENSE",
    "PercentPhaseFOV": 100,
    "PercentSampling": 100,
    "EchoTrainLength": 90,
    "AcquisitionMatrixPE": 90,
    "ReconMatrixPE": 90,
    "BandwidthPerPixelPhaseEncode": 21.786,
    "EffectiveEchoSpacing": 0.000510012,
    "DerivedVendorReportedEchoSpacing": 0.000510012,
    "AcquisitionDuration": 13.895,
    "TotalReadoutTime": 0.045391,
    "PixelBandwidth": 2778,
    "DwellTime": 2e-06,
    "PhaseEncodingDirection": "j",
    "SliceTiming": [
        3.505,
        0,
        3.6225,
        0.115,
        3.74,
        0.2325,
        3.855,
        0.35,
        3.9725,
        0.4675,
        4.09,
        0.5825,
        4.2075,
        0.7,
        4.3225,
        0.8175,
        4.44,
        0.935,
        4.5575,
        1.05,
        4.675,
        1.1675,
        4.79,
        1.285,
        4.9075,
        1.4025,
        5.025,
        1.5175,
        5.1425,
        1.635,
        5.2575,
        1.7525,
        5.375,
        1.87,
        5.4925,
        1.985,
        5.61,
        2.1025,
        5.725,
        2.22,
        5.8425,
        2.3375,
        5.96,
        2.4525,
        6.0775,
        2.57,
        6.1925,
        2.6875,
        6.31,
        2.805,
        6.4275,
        2.92,
        6.545,
        3.0375,
        6.66,
        3.155,
        6.7775,
        3.2725,
        6.895,
        3.3875
    ],
    "ImageOrientationPatientDICOM": [
        1,
        0,
        0,
        0,
        1,
        0
    ],
    "InPlanePhaseEncodingDirectionDICOM": "COL",
    "ConversionSoftware": "dcm2niix",
    "ConversionSoftwareVersion": "v1.0.20220720",
    "Dcm2bidsVersion": "2.1.4",
    "IntendedFor": [
        "func/subjID_task-EmoMale_bold.nii.gz",
        "func/subjID_task-EmoFemale_bold.nii.gz"
    ]
}

In derivatives folder (“subjID_acq-Neut_fmapid-auto00001_desc-preproc_fieldmap”):

{
  "AnatomicalReference": "subjID_acq-Neut_fmapid-auto00001_desc-epi_fieldmap.nii.gz",
  "AssociatedCoefficients": [
    "subjID_acq-Neut_fmapid-auto00001_desc-coeff_fieldmap.nii.gz"
  ],
  "B0FieldIdentifier": "auto_00001",
  "IntendedFor": [
    "func/subjID_task-EmoFemale_bold.nii.gz",
    "func/subjID_task-EmoMale_bold.nii.gz"
  ],
  "RawSources": [
    "bids/subjID/fmap/subjID_acq-Neut_dir-AP_run-01_epi.nii.gz",
    "bids/subjID/fmap/subjID_acq-Neut_dir-AP_run-02_epi.nii.gz",
    "bids/subjID/fmap/subjID_acq-Neut_dir-PA_run-01_epi.nii.gz",
    "bids/subjID/fmap/subjID_acq-Neut_dir-PA_run-02_epi.nii.gz"
  ],
  "Units": "Hz"
}

Hi @dani

It could be from SDCFlows updates between those two versions. Yes, please fix fmap assignments and try again.

Best,
Steven

1 Like

Hi @Steven and @effigies
Things look much better in the new version, thanks again for your help!
best,
Dani