Slice-timing illegal values in fmriprep

Hello all,

I was trying to run fmriprep (using docker), but was running into some errors with slice time correction specifically an illegal value. I pasted the output of my json below. I also included the output from the fmriprep html. I wondered if others had run into this before? I thought the values were “valid” and wasn’t sure what I might be doing wrong. Have others run into this issue?

Any thoughts are greatly appreciated!
Thanks much!
Jamie.


FROM FMRIPREP HTML
Traceback (most recent call last):
File “/usr/local/miniconda/lib/python3.6/site-packages/niworkflows/nipype/pipeline/plugins/multiproc.py”, line 62, in run_node
result[‘result’] = node.run(updatehash=updatehash)
File “/usr/local/miniconda/lib/python3.6/site-packages/niworkflows/nipype/pipeline/engine/nodes.py”, line 441, in run
result = self._run_interface(execute=True)
File “/usr/local/miniconda/lib/python3.6/site-packages/niworkflows/nipype/pipeline/engine/nodes.py”, line 518, in _run_interface
return self._run_command(execute)
File “/usr/local/miniconda/lib/python3.6/site-packages/niworkflows/nipype/pipeline/engine/nodes.py”, line 594, in _run_command
result = self._interface.run()
File “/usr/local/miniconda/lib/python3.6/site-packages/niworkflows/nipype/interfaces/base/core.py”, line 485, in run
runtime = self._run_interface(runtime)
File “/usr/local/miniconda/lib/python3.6/site-packages/niworkflows/nipype/interfaces/afni/base.py”, line 110, in _run_interface
return super(AFNICommandBase, self)._run_interface(runtime)
File “/usr/local/miniconda/lib/python3.6/site-packages/niworkflows/nipype/interfaces/base/core.py”, line 973, in _run_interface
self.raise_exception(runtime)
File “/usr/local/miniconda/lib/python3.6/site-packages/niworkflows/nipype/interfaces/base/core.py”, line 912, in raise_exception
**runtime.dictcopy()))
RuntimeError: Command:
3dTshift -ignore 2 -prefix sub-NDARFJ803JF7_task-rest_run-1_bold_valid_tshift.nii.gz -tpattern @/home/jamielh/Volumes/Hanson/NKI_HealthyBrainNetwork/CBIC/R3/derivatives/working/fmriprep_wf/single_subject_NDARFJ803JF7_wf/func_preproc_task_rest_run_1_wf/bold_stc_wf/create_custom_slice_timing_file/timings.1D -TR 0.8s /home/jamielh/Volumes/Hanson/NKI_HealthyBrainNetwork/CBIC/R3/derivatives/working/fmriprep_wf/single_subject_NDARFJ803JF7_wf/func_preproc_task_rest_run_1_wf/bold_stc_wf/slice_timing_correction/sub-NDARFJ803JF7_task-rest_run-1_bold_valid.nii.gz
Standard output:

Standard error:
++ 3dTshift: AFNI version=Debian-16.2.07~dfsg.1-5~nd16.04+1 (Jun 12 2017) [64-bit]
e[7m*+ WARNING:e[0m If you are performing spatial transformations on an oblique dset,
such as /home/jamielh/Volumes/Hanson/NKI_HealthyBrainNetwork/CBIC/R3/derivatives/working/fmriprep_wf/single_subject_NDARFJ803JF7_wf/func_preproc_task_rest_run_1_wf/bold_stc_wf/slice_timing_correction/sub-NDARFJ803JF7_task-rest_run-1_bold_valid.nii.gz,
or viewing/combining it with volumes of differing obliquity,
you should consider running:
3dWarp -deoblique
on this and other oblique datasets in the same session.
See 3dWarp -help for details.
++ Oblique dataset:/home/jamielh/Volumes/Hanson/NKI_HealthyBrainNetwork/CBIC/R3/derivatives/working/fmriprep_wf/single_subject_NDARFJ803JF7_wf/func_preproc_task_rest_run_1_wf/bold_stc_wf/slice_timing_correction/sub-NDARFJ803JF7_task-rest_run-1_bold_valid.nii.gz is 13.390522 degrees from plumb.
e[7m** FATAL ERROR:e[0m Illegal value 0.863996 in tpattern file /home/jamielh/Volumes/Hanson/NKI_HealthyBrainNetwork/CBIC/R3/derivatives/working/fmriprep_wf/single_subject_NDARFJ803JF7_wf/func_preproc_task_rest_run_1_wf/bold_stc_wf/create_custom_slice_timing_file/timings.1D
** Program compile date = Jun 12 2017
Return code: 1


JSON FILE–
{
“InPlanePhaseEncodingDirectionDICOM”: “COL”,
“BaseResolution”: 90,
“ConsistencyInfo”: “N4_VE11B_LATEST_20150530”,
“ImageComments”: “SMS_ABCD_V1.0;_MB=6;_FOVshift=3;_K_PE=5;_K_RO=5;_CCR=1;_LeakBlockOn;”,
“ProcedureStepDescription”: “CMI_HBN-CBIC”,
“DeviceSerialNumber”: “67080”,
“AcquisitionMatrixPE”: 90,
“ImageOrientationPatientDICOM”: [
0.999691,
-0.00572891,
-0.0242053,
-3.49687e-08,
0.973115,
-0.230319
],
“EffectiveEchoSpacing”: 0.000500005,
“TotalReadoutTime”: 0.0445004,
“ManufacturersModelName”: “Prisma_fit”,
“ProtocolName”: “ABCD_REST1”,
“BandwidthPerPixelPhaseEncode”: 22.222,
“RepetitionTime”: 0.8,
“BodyPartExamined”: “BRAIN”,
“MagneticFieldStrength”: 3,
“PhaseEncodingSteps”: 90,
“MRAcquisitionType”: “2D”,
“SliceThickness”: 2.4,
“DwellTime”: 2.1e-06,
“TxRefAmp”: 220.21,
“MultibandAccelerationFactor”: 6,
“ImageType”: [
“ORIGINAL”,
“PRIMARY”,
“M”,
“ND”,
“MOSAIC”
],
“DerivedVendorReportedEchoSpacing”: 0.000500005,
“SeriesDescription”: “ABCD_REST1”,
“SAR”: 0.301098,
“ConversionSoftware”: “dcm2niix”,
“ScanningSequence”: “EP”,
“Manufacturer”: “Siemens”,
“PercentPhaseFOV”: 100,
“StationName”: “MRTRIO3TX72”,
“ReconMatrixPE”: 90,
“FlipAngle”: 52,
“PulseSequenceDetails”: “%CustomerSeq%_ep2d_bold_sms_abcd”,
“PartialFourier”: 1,
“ConversionSoftwareVersion”: “v1.0.20171204 (OpenJPEG build) GCC4.8.4”,
“ShimSetting”: [
191,
-10412,
-5667,
453,
62,
-177,
157,
2
],
“PatientPosition”: “HFS”,
“SequenceName”: “epfSM2d1_90”,
“ReceiveCoilName”: “Head_32”,
“TaskName”: “Resting”,
“SpacingBetweenSlices”: 2.4,
“ReceiveCoilActiveElements”: “HEA;HEP”,
“EchoTime”: 0.03,
“SequenceVariant”: “SK”,
“SliceTiming”: [
0,
0.863996,
0.0725,
0.863997,
0.1475,
0.863998,
0.22,
0.863999,
0.2925,
0.863999,
0.365,
0,
0.863996,
0.0725,
0.863997,
0.1475,
0.863998,
0.22,
0.863999,
0.2925,
0.863999,
0.365,
0,
0.863996,
0.0725,
0.863997,
0.1475,
0.863998,
0.22,
0.863999,
0.2925,
0.863999,
0.365,
0,
0.863996,
0.0725,
0.863997,
0.1475,
0.863998,
0.22,
0.863999,
0.2925,
0.863999,
0.365,
0,
0.863996,
0.0725,
0.863997,
0.1475,
0.863998,
0.22,
0.863999,
0.2925,
0.863999,
0.365,
0,
0.863996,
0.0725,
0.863997,
0.1475,
0.863998,
0.22,
0.863999,
0.2925,
0.863999,
0.365
],
“PhaseResolution”: 1,
“EchoTrainLength”: 90,
“PhaseEncodingDirection”: “j-”,
“ScanOptions”: “FS”,
“SoftwareVersions”: “syngo_MR_E11”,
“PixelBandwidth”: 2645,
“Modality”: “MR”
}

There is clearly something wrong with your SliceTiming field. The values are spaced in a weird way and there are multiple ones that are larger than your RepetitionTime (0.8).

Hmmm, that’s odd (and challenging… since I’m trying to use public-access data). I edited the slice time header previously, but here I also pasted the original below. That’s likely not any better (unless I’m missing something, eh?) I ran into this issue before… and thought that would be a work-around.


JSON (pre-edits)
{
“InPlanePhaseEncodingDirectionDICOM”: “COL”,
“BaseResolution”: 90,
“ConsistencyInfo”: “N4_VE11B_LATEST_20150530”,
“ImageComments”: “SMS_ABCD_V1.0;_MB=6;_FOVshift=3;_K_PE=5;_K_RO=5;_CCR=1;_LeakBlockOn;”,
“ProcedureStepDescription”: “CMI_HBN-CBIC”,
“DeviceSerialNumber”: “67080”,
“AcquisitionMatrixPE”: 90,
“ImageOrientationPatientDICOM”: [
0.999691,
-0.00572891,
-0.0242053,
-3.49687e-08,
0.973115,
-0.230319
],
“EffectiveEchoSpacing”: 0.000500005,
“TotalReadoutTime”: 0.0445004,
“ManufacturersModelName”: “Prisma_fit”,
“ProtocolName”: “ABCD_REST1”,
“BandwidthPerPixelPhaseEncode”: 22.222,
“RepetitionTime”: 0.8,
“BodyPartExamined”: “BRAIN”,
“MagneticFieldStrength”: 3,
“PhaseEncodingSteps”: 90,
“MRAcquisitionType”: “2D”,
“SliceThickness”: 2.4,
“DwellTime”: 2.1e-06,
“TxRefAmp”: 220.21,
“MultibandAccelerationFactor”: 6,
“ImageType”: [
“ORIGINAL”,
“PRIMARY”,
“M”,
“ND”,
“MOSAIC”
],
“DerivedVendorReportedEchoSpacing”: 0.000500005,
“SeriesDescription”: “ABCD_REST1”,
“SAR”: 0.301098,
“ConversionSoftware”: “dcm2niix”,
“ScanningSequence”: “EP”,
“Manufacturer”: “Siemens”,
“PercentPhaseFOV”: 100,
“StationName”: “MRTRIO3TX72”,
“ReconMatrixPE”: 90,
“FlipAngle”: 52,
“PulseSequenceDetails”: “%CustomerSeq%_ep2d_bold_sms_abcd”,
“PartialFourier”: 1,
“ConversionSoftwareVersion”: “v1.0.20171204 (OpenJPEG build) GCC4.8.4”,
“ShimSetting”: [
191,
-10412,
-5667,
453,
62,
-177,
157,
2
],
“PatientPosition”: “HFS”,
“SequenceName”: “epfSM2d1_90”,
“ReceiveCoilName”: “Head_32”,
“TaskName”: “Resting”,
“SpacingBetweenSlices”: 2.4,
“ReceiveCoilActiveElements”: “HEA;HEP”,
“EchoTime”: 0.03,
“SequenceVariant”: “SK”,
“SliceTiming”: [
0,
86399.6,
0.0725,
86399.7,
0.1475,
86399.8,
0.22,
86399.9,
0.2925,
86399.9,
0.365,
0,
86399.6,
0.0725,
86399.7,
0.1475,
86399.8,
0.22,
86399.9,
0.2925,
86399.9,
0.365,
0,
86399.6,
0.0725,
86399.7,
0.1475,
86399.8,
0.22,
86399.9,
0.2925,
86399.9,
0.365,
0,
86399.6,
0.0725,
86399.7,
0.1475,
86399.8,
0.22,
86399.9,
0.2925,
86399.9,
0.365,
0,
86399.6,
0.0725,
86399.7,
0.1475,
86399.8,
0.22,
86399.9,
0.2925,
86399.9,
0.365,
0,
86399.6,
0.0725,
86399.7,
0.1475,
86399.8,
0.22,
86399.9,
0.2925,
86399.9,
0.365
],
“PhaseResolution”: 1,
“EchoTrainLength”: 90,
“PhaseEncodingDirection”: “j-”,
“ScanOptions”: “FS”,
“SoftwareVersions”: “syngo_MR_E11”,
“PixelBandwidth”: 2645,
“Modality”: “MR”
}

This one also includes slice timing values larger than repetition time. Which dataset is it?

1 Like

Healthy Brain Network. I’ll follow-up with that group to see if they have thoughts.

1 Like

Latest version of the bids-validator checks for this error so you can ask them to use it.

1 Like

Did you ever figure this out, @jamielarshanson? I am looking at similarly odd slice times in ABCD data (which looks like it uses a similar sequence) from Siemens scanner.

1 Like

Found out that this also plagues a few (8 of the 140 subjects at one site that I’ve checked) of the BOLD scans in ABCD. It’s due to negative slices times in the CSA header (see below), which then turns into an overflow error when they are ‘read’ as unsigned. Take-home message is that the huge numbers are a result of negative values overflowing, but the source of the negative values is unknown, will go back to the dataset folks.

(0019,1029) FD 0\-400\80\-320\160\-240\240\-160\320\-80\0\-400\80\-320\160\-240\240\-160\320\-80\0\-400\80\-320\160\-240\240\-160\320\-80\0\-400\80\-320\160\-240\240\-160\320\-80\0\-400\80\-320\160\-240\240\-160\320\-80\0\-400\80\-320\160\-240\240\-160\320\-80         # 480,1-n MosaicRefAcqTimes

@Ursula_Tooley the BIDS sidecar will also report the version of dcm2niix used. Can you please ensure the latest version v1.0.20181125 was used? This sounds a lot like an issue first described in October 2018 where Siemens Motion Correction reports the acquisition times as negative values.

Siemens explanation for this is that motion correction images sorted into anatomic order, while the non-moco data are in descending order, so the latest time is subtracted from each acquisition time resulting in the negative values.

Personally, I would never acquire online motion corrected images, as I think the offline tools are more useful. However, recent versions of dcm2niix should handle these.

If this does not resolve the problem, is it possible to share the first few volumes of data with me and post an issue on Github. The other explanation I can think of is that the CSA header of the first volume is not correctly populated, but the subsequent ones might be OK.

2 Likes

Siemens scanners can generate negative slice times if Motion Correction (MoCo) is enabled. The development branch of dcm2niix fixes this using a formula provided by Siemens. Feel free to validate this solution, unless there are any concerns it will be included in the next stable release of dcm2niix.

Thank you so much, @Chris_Rorden, and my apologies for the delay in coming back to this! I tried the development build as suggested, and posted my concerns here–just cross-posting for thoroughness.

1 Like

In case @jamielarshanson or others encounter this, documentation of the issue affecting the first volume of the sequence here: https://github.com/rordenlab/dcm2niix/issues/271

1 Like