Fmriprep fieldmap (phasediff) error: file magnitude2 not found

Hi all

i tried to run fmriprep with fieldmap correction using a phasediff image and one magnitude image. According to the BIDS documentation Case 1: Phase difference image and at least one magnitude image. I got the following error:

traits.trait_errors.TraitError: The trait ‘in_files’ of an IntraModalMergeInputSpec instance is an existing file name, but the path ‘/data/sub-01/ses-01/fmap/sub-01_ses-01_magnitude2.nii’ does not exist.

It seems to search for another magnitude image but according to the BIDS structure i only need one?

Thanks for the help.

Best wishes

Can you share your actual BIDS tree (the tree command is useful here, if you have it), and the contents of the relevant .json files for your fieldmaps?

I have a suspicion there might be an issue with expecting .nii vis .nii.gz.

I had the same problem (also have one phasediff and one magnitude-image), but I “solved” it by copying the magnitude image and renaming the original one “*magnitude1.nii.gz” and the copied one “*magnitude2.nii.gz”, which then resolved the error when running fmriprep. Perhaps this info helps in debugging the issue!

Hi, this is the information from the json file in the fieldmap folder

"Manufacturer": "Philips",
"ManufacturersModelName": "N/A",
"ProtocolName": "B0_T1W_FFE_222CLEARtool4.1",
"ImageType": ["ORIGINAL"],
"PhilipsRescaleSlope": 1.72747,
"PhilipsRescaleIntercept": 0,
"PhilipsScaleSlope": 0.0216547,
"UsePhilipsFloatNotDisplayScaling": 1,
"RepetitionTime": 0.4,
"ConversionSoftware": "dcm2niix",
"ConversionSoftwareVersion": "v1.0.20170207 (openJPEG build)",
"EchoTime1": 0.0044,
"EchoTime2": 0.0067,
"EffectiveEchoSpacing": 0.001027725,
"PhaseEncodingDirection": "j",
"SliceEncodingDirection": "k",
"IntendedFor": "ses-01/func/sub-01_ses-01_task-food_bold.nii"

json from task file:

“Manufacturer”: “Philips”,
“ManufacturersModelName”: “N/A”,
“ProtocolName”: “FoodTaskfMRISENSEtool4.1”,
“ImageType”: [“ORIGINAL”],
“PhilipsRescaleSlope”: 1.76801,
“PhilipsRescaleIntercept”: 0,
“PhilipsScaleSlope”: 0.0111859,
“UsePhilipsFloatNotDisplayScaling”: 1,
“EchoTime”: 0.03,
“RepetitionTime”: 2.3,
“ConversionSoftware”: “dcm2niix”,
“ConversionSoftwareVersion”: “v1.0.20170207 (openJPEG build)”,
“EffectiveEchoSpacing”: 0.00033,
“PhaseEncodingDirection”: “j”,
“SliceEncodingDirection”: “k”

├── sub-01
│ ├── ses-01
│ │ ├── anat
│ │ │ ├── 10_10042014_1726460_13_1_t13dtfesagseV41.par
│ │ │ ├── 10_10042014_1726460_13_1_t13dtfesagseV41.rec
│ │ │ ├── sub-01_ses-01_T1w.json
│ │ │ ├── sub-01_ses-01_T1w.nii
│ │ │ └── sub-01_ses-01_T1w_seg8.mat
│ │ ├── dwi
│ │ ├── fmap
│ │ │ ├── sub-01_ses-01_magnitude1.nii
│ │ │ ├── sub-01_ses-01_phasediff.json
│ │ │ └── sub-01_ses-01_phasediff.nii
│ │ └── func
│ │ ├── 10_10042014_1620460_4_1_foodtaskfmrisenV41.par
│ │ ├── 10_10042014_1620460_4_1_foodtaskfmrisenV41.rec
│ │ ├── preproc_food.mat
│ │ ├── sub-01_ses-01_task-food_bold.json
│ │ ├── sub-01_ses-01_task-food_bold.nii
│ │ └── sub-01_ses-01_task-food_events.tsv
│ ├── ses-02
│ │ ├── anat
│ │ ├── dwi
│ │ └── func
│ └── ses-03
│ ├── anat
│ ├── dwi
│ └── func
└── task-food_bold.json

Thanks for the help.

Hi @silvano, thanks for the information, and sorry about my slow response. (I’ve been otherwise occupied for about three weeks, one way or another.)

It looks like the issue is that you only have magnitude1.nii, while the phasediff workflow we have expects both magnitude1.nii and magnitude2.nii.

Can you run nib-ls on your magnitude1.nii file? I’m curious whether it’s a 4D file with two volumes.

Hi effigies

This is the output of the nib-ls command on the file.
sub-01_ses-01_magnitude1.nii int16 [128, 128, 77] 2.00x2.00x2.00

Thank you.

Okay, so it’s only one volume. For now, you’ll need to add --ignore fieldmaps to your fmriprep command, because we don’t support phasediff distortion correction without both magnitude1 and magnitude2.

I’ve opened an issue on the fmriprep Github to be sure that we handle this case correctly, whether it is to disable fieldmaps or to use an alternative algorithm. Please direct any further discussion, there.

This will be fixed with this bugfix: