BIDS error code 66: slice timing error

Meteorxy · August 5, 2022, 2:03pm

Hi! I am new to BIDS and am trying to convert my dataset to the format using dcm2bids. After I threw my data into validator it gave me the error:
Code 66 SLICETIMING_VALUES_GREATOR_THAN_REPETITION_TIME**

Could you tell me how to fix this? Thanks!

Here is the relevant part in json file for the data:
“RepetitionTime”: 1.55
“SliceTiming”: [
0,
2.2975,
0.0475,
2.345,
0.0975,
2.395,
0.145,
2.4425,
0.195,
2.4925,
0.2425,
2.54,
0.2925,
2.59,
0.3425,
2.64,
0.39,
2.6875,
0.44,
2.7375,
0.4875,
2.785,
0.5375,
2.835,
0.585,
2.8825,
0.635,
2.9325,
0.6825,
2.98,
0.7325,
3.03,
0.7825,
3.08,
0.83,
3.1275,
0.88,
3.1775,
0.9275,
3.225,
0.9775,
3.275,
1.025,
3.3225,
1.075,
3.3725,
1.1225,
3.42,
1.1725,
3.47,
1.22,
3.52,
1.27,
3.5675,
1.32,
3.6175,
1.3675,
3.665,
1.4175,
3.715,
1.465,
3.7625,
1.515,
3.8125,
1.5625,
3.86,
1.6125,
3.91,
1.66,
3.96,
1.71,
4.0075,
1.76,
4.0575,
1.8075,
4.105,
1.8575,
4.155,
1.905,
4.2025,
1.955,
4.2525,
2.0025,
4.3,
2.0525,
4.35,
2.1,
4.4,
2.15,
4.4475,
2.2,
4.4975,
2.2475
],

neurolabusc · August 5, 2022, 2:50pm

@Meteorxy please provide the entire JSON file to provide context. Without these details, I would speculate that your data was acquired on a Siemens scanner running the CMRR research sequences. The CMRR sequences can elicit this error for one of two reasons.

The CMRR single band reference series can erroneously report the TR of the multi-band sequence. Since SBRefs are typically only a single volume, there is no possibility for slice timing correction, so this is not an issue.
The first volume of a CMRR multi-band series erroneously reports the slice timing of the single band reference. This assumes your data were acquired before CMRR R011. Recent versions of dcm2niix are aware of this issue, so they use the 2nd volume in the time series. This suggests that dcm2bids used an obsolete version of dcm2niix. The solution is to upgrade dcm2niix to the current stable release.

Meteorxy · August 5, 2022, 3:59pm

Hi,
Thank you for the response! You are right that I am acquiring using CMRR with a Siemens machine. I just checked and it seems that the dcm2niix version is up-to-date. Could it be the first error you mentioned?

Here is the full json file:

{
“Modality”: “MR”,
“MagneticFieldStrength”: 6.98,
“ImagingFrequency”: 297.204,
“Manufacturer”: “Siemens”,
“ManufacturersModelName”: “Investigational_Device_7T”,
“InstitutionName”: “EPFL”,
“InstitutionalDepartmentName”: “CIBM”,
“InstitutionAddress”: “Noyerettes CH porte F,Lausanne,VD,CH,1015”,
“DeviceSerialNumber”: “18931”,
“StationName”: “MRC18931”,
“PatientPosition”: “HFS”,
“ProcedureStepDescription”: “RESEARCH”,
“SoftwareVersions”: “syngo MR B17”,
“MRAcquisitionType”: “2D”,
“SeriesDescription”: “Rest_1.3mm_TR1.55_ipat3x3”,
“ProtocolName”: “Rest_1.3mm_TR1.55_ipat3x3”,
“ScanningSequence”: “EP”,
“SequenceVariant”: “SK”,
“SequenceName”: “epfid2d1_152”,
“ImageType”: [
“ORIGINAL”,
“PRIMARY”,
“M”,
“ND”,
“MOSAIC”
],
“NonlinearGradientCorrection”: false,
“SeriesNumber”: 43,
“AcquisitionTime”: “11:00:38.297500”,
“AcquisitionNumber”: 1,
“SliceThickness”: 1.3,
“SpacingBetweenSlices”: 1.43,
“SAR”: 0.0805458,
“EchoTime”: 0.026,
“RepetitionTime”: 1.55,
“FlipAngle”: 63,
“PartialFourier”: 1,
“BaseResolution”: 152,
“ShimSetting”: [
-1,
129,
904,
2,
13,
-130,
120,
-263
],
“TxRefAmp”: 220,
“PhaseResolution”: 1,
“ReceiveCoilName”: “32Ch_Head_7T”,
“CoilString”: “C:A32”,
“PulseSequenceDetails”: “%CustomerSeq%\ep2d_bold_SliceAcc770A_CIBM”,
“RefLinesPE”: 54,
“CoilCombinationMethod”: “Sum of Squares”,
“MatrixCoilMode”: “GRAPPA”,
“PercentPhaseFOV”: 100,
“PercentSampling”: 100,
“PhaseEncodingSteps”: 152,
“AcquisitionMatrixPE”: 152,
“ReconMatrixPE”: 152,
“BandwidthPerPixelPhaseEncode”: 27.412,
“ParallelReductionFactorInPlane”: 3,
“EffectiveEchoSpacing”: 0.000240002,
“DerivedVendorReportedEchoSpacing”: 0.000720007,
“TotalReadoutTime”: 0.0362404,
“PixelBandwidth”: 1566,
“DwellTime”: 2.1e-06,
“PhaseEncodingDirection”: “j-”,
“SliceTiming”: [
0,
2.2975,
0.0475,
2.345,
0.0975,
2.395,
0.145,
2.4425,
0.195,
2.4925,
0.2425,
2.54,
0.2925,
2.59,
0.3425,
2.64,
0.39,
2.6875,
0.44,
2.7375,
0.4875,
2.785,
0.5375,
2.835,
0.585,
2.8825,
0.635,
2.9325,
0.6825,
2.98,
0.7325,
3.03,
0.7825,
3.08,
0.83,
3.1275,
0.88,
3.1775,
0.9275,
3.225,
0.9775,
3.275,
1.025,
3.3225,
1.075,
3.3725,
1.1225,
3.42,
1.1725,
3.47,
1.22,
3.52,
1.27,
3.5675,
1.32,
3.6175,
1.3675,
3.665,
1.4175,
3.715,
1.465,
3.7625,
1.515,
3.8125,
1.5625,
3.86,
1.6125,
3.91,
1.66,
3.96,
1.71,
4.0075,
1.76,
4.0575,
1.8075,
4.105,
1.8575,
4.155,
1.905,
4.2025,
1.955,
4.2525,
2.0025,
4.3,
2.0525,
4.35,
2.1,
4.4,
2.15,
4.4475,
2.2,
4.4975,
2.2475
],
“ImageOrientationPatientDICOM”: [
1,
0,
1e-16,
0,
0.795474,
-0.605988
],
“ImageOrientationText”: “Tra>Cor(-37.3)”,
“InPlanePhaseEncodingDirectionDICOM”: “COL”,
“ConversionSoftware”: “dcm2niix”,
“ConversionSoftwareVersion”: “v1.0.20220720”,
“Dcm2bidsVersion”: “2.1.7”
}

Chris_Rorden · August 5, 2022, 4:22pm

If the image data is a 3D volume rather than a 4D time series, this looks like a multi band reference that does not correctly report the TR. I also note that the BIDS field MultibandAccelerationFactor is not set, which would also support this hypothesis. If this is a 3D SBRef, I think the TR will be very close to 4.545 seconds. (0.0475 + 4.4975) and you could simply set it to that value.

Meteorxy · August 5, 2022, 5:03pm

Thanks for the response. But this is indeed a 4D time series image. Are there any other possibilities that caused this problem?

neurolabusc · August 5, 2022, 5:48pm

Can you send a link so I can download the DICOMs to my institutional email? I have never seen 7T B17 CMRR datasets, but it seems likely that this is a variant of the CMRR bug that impacts more than a single volume. The other option is that some anonymization tool removed vital DICOM tags from your data (e.g. the CSA header) but this seems unlikely as I would not expect SliceTiming to be populated.