Fmriprep processing error : " The number of elements in the SliceTiming array should match the 'k' dimension of the corresponding NIfTI volume"

,
1

Dear Experts,

I have a problem when running fmri prep (v fMRIPrep 21.0.1)

I am using the following command :

singularity run --cleanenv /shared/images/fmriprep_latest.sif dataset_test/ output/ participant --participant-label sub-001 --fs-license-file /shared/sandbox_fmriprep/license.txt --force-bbr --n_cpus 1 --ignore slicetiming sbref fieldmaps

At first I have the following warning :

1: [WARN] The number of elements in the SliceTiming array should match the 'k' dimension of the corresponding NIfTI volume. (code: 87 - SLICETIMIN$
    ./sub-001/func/sub-001_task-rest_acq-TR1430_bold.nii.gz
Evidence: SliceTiming array is of length 1 and the value of the 'k' dimension is 81 for the corresponding nifti header.

Later on, I have the following error message :

As I have added in my command line the flag --ignore slicetiming sbref, I was wondering if you confirm that this error message is related to slice timing (which is strange, because I added the flag “ignore slicetiming” or if it is another problem.

Thank you very much in advance for your help !

220807-06:09:46,61 nipype.workflow IMPORTANT:
         Building fMRIPrep's workflow:
           * BIDS dataset path: /dataset_test.
           * Participant list: ['001'].
           * Run identifier: 20220807-060933_0927f016-6711-4be2-aa0f-cc3f0d4aa735.
           * Output spaces: MNI152NLin2009cAsym:res-native.
           * Pre-run FreeSurfer's SUBJECTS_DIR: /ocean/projects/med220002p/shared/noomane/charles/output/sourcedata/freesurfer.
220807-05:31:56,122 nipype.workflow INFO:
	 No single-band-reference found for sub-001_task-rest_acq-TR1430_bold.nii.gz.
Process Process-2:
Traceback (most recent call last):
  File "/opt/conda/lib/python3.8/multiprocessing/process.py", line 315, in _bootstrap
    self.run()
  File "/opt/conda/lib/python3.8/multiprocessing/process.py", line 108, in run
    self._target(*self._args, **self._kwargs)
  File "/opt/conda/lib/python3.8/site-packages/fmriprep/cli/workflow.py", line 118, in build_workflow
    retval["workflow"] = init_fmriprep_wf()
  File "/opt/conda/lib/python3.8/site-packages/fmriprep/workflows/base.py", line 85, in init_fmriprep_wf
    single_subject_wf = init_single_subject_wf(subject_id)
  File "/opt/conda/lib/python3.8/site-packages/fmriprep/workflows/base.py", line 370, in init_single_subject_wf
    func_preproc_wf = init_func_preproc_wf(bold_file, has_fieldmap=has_fieldmap)
  File "/opt/conda/lib/python3.8/site-packages/fmriprep/workflows/bold/base.py", line 395, in init_func_preproc_wf
    func_derivatives_wf = init_func_derivatives_wf(
  File "/opt/conda/lib/python3.8/site-packages/fmriprep/workflows/bold/outputs.py", line 164, in init_func_derivatives_wf
    timing_parameters = prepare_timing_parameters(metadata)
  File "/opt/conda/lib/python3.8/site-packages/fmriprep/workflows/bold/outputs.py", line 96, in prepare_timing_parameters
    TA = st[-1] + (st[1] - st[0])  # Final slice onset - slice duration
IndexError: list index out of range
2

Can you share the value of SliceTiming in the associated json file for sub-001/func/sub-001_task-rest_acq-TR1430_bold.nii.gz? Given that you are ignoring slice-timing, I imagine the error is unrelated to that validation warning. Still, it would probably be a good thing to address.

I think the error traceback you posted is incomplete. It looks like it was cut off. Can you update your post with the full traceback?

1 Like
3

Thank you !

I updated my post and the traceback is now complete.
Here is the json file associated with the bold nifti file that raised the error.
I had a problem when converting my dcm to nifti with MRICron (dcm2niix) as described here, dcm2niix was producing a “mosaic” instead of really converting my file Conversion Issue: Can't read Mosaic · Issue #275 · rordenlab/dcm2niix · GitHub. This seems to be related to my dcm file that comes from a 3T Siemens Prisma. So I converted my dcm file to nifti using the old version of MRICron (dcm2nii instead of dcm2niix). However, as dcm2nii does not produce the json file, I used dcm2niix to produce the json file, which is why I think there is a problem with the slicetiming.
However, as I added the flag --ignore slicetiming, my uderstanding was that it should not be a problem…

{
	"Modality": "MR",
	"MagneticFieldStrength": 3,
	"ImagingFrequency": 123.255,
	"Manufacturer": "Siemens",
	"ManufacturersModelName": "Prisma",
	"InstitutionName": "CHE",
	"InstitutionalDepartmentName": "Department",
	"InstitutionAddress": "Av._du_Ma",
	"DeviceSerialNumber": "166191",
	"StationName": "AWP166191",
	"BodyPartExamined": "BRAIN",
	"PatientPosition": "HFS",
	"ProcedureStepDescription": "IRM_cranio-encephalique",
	"SoftwareVersions": "syngo_MR_E11",
	"MRAcquisitionType": "2D",
	"SeriesDescription": "ep2d_bold_moco_p2_s2_Resting_State",
	"ProtocolName": "ep2d_bold_moco_p2_s2_Resting_State",
	"ScanningSequence": "EP",
	"SequenceVariant": "SK",
	"ScanOptions": "FS",
	"SequenceName": "_epfid2d1_94",
	"ImageType": ["ORIGINAL", "PRIMARY", "M", "ND", "MOSAIC"],
	"SeriesNumber": 6,
	"AcquisitionTime": "18:34:18.227500",
	"AcquisitionNumber": 1,
	"SliceThickness": 2,
	"SpacingBetweenSlices": 2,
	"SAR": 0.0562544,
	"EchoTime": 0.025,
	"RepetitionTime": 2,
	"FlipAngle": 80,
	"PartialFourier": 0.5,
	"PercentPhaseFOV": 100,
	"EchoTrainLength": 47,
	"PhaseEncodingSteps": 94,
	"AcquisitionMatrixPE": 94,
	"ReconMatrixPE": 846,
	"PixelBandwidth": 1565,
	"PhaseEncodingAxis": "j",
	"SliceTiming": [
		0	],
	"ImageOrientationPatientDICOM": [
		0.99898,
		-0.00700342,
		0.0446052,
		0.0113336,
		0.995163,
		-0.097578	],
	"InPlanePhaseEncodingDirectionDICOM": "COL",
	"ConversionSoftware": "dcm2niix",
	"ConversionSoftwareVersion": "v1.0.20190902",
	"TaskName": "rest"
}
4

Thank you! Unfortunately, based on your traceback, it looks like fMRIPrep will check the SliceTiming even when you ask it to ignore slice timing. It may just be a validation thing.

I’m not really familiar with mosaics, so I can’t help with converting those files, though it looks like you have that handled already.

The SliceTiming parameter is definitely wrong, but it also seems odd that there are apparently 81 slices in your image file, given the fact that the SliceThickness is 2mm and the SpacingBetweenSlices is also 2mm. Is there any chance that the length of the run is 81 volumes, and MRICron ended up concatenating just one of the slices from each volume into a 3D nifti instead of a 4D nifti?

Assuming that the converted nifti looks good, I would recommend either replacing the SliceTiming field in your json with the correct slice times (which you may need to look into the dicom headers or protocol sheet for) or maybe just remove the SliceTiming field completely. SliceTiming is recommended, but not required, in BIDS, except in sparse sequences. Since you’re already ignoring slice timing, removing the field shouldn’t cause any real problems with this fMRIPrep call.

1 Like