I got this on a Siemens Prisma_fit VE11C using dcm2niix v1.0.20181125 GCC4.8.5:
Error code 66: SLICETIMING_VALUES_GREATOR_THAN_REPETITION_TIME
upon close examination, it seems like it’s not really an error of the wrong unit (ms vs. seconds), but the TR reported (70) is per slice, rather than per volume. Have people seen this ?
What kind of sequence was used to create those images? I guess it is a kind of 2D EPI sequence?
Also, I advise you to use a more recent version of dcm2niix: v1.0.20211006 (Release version 6-October-2021 (v1.0.20211006) · rordenlab/dcm2niix · GitHub)
1 Like
@ins0mniac2 I also think you should use a more recent version of dcm2niix.
It might also help if you include the entire json that was created to understand the sequence used. In general, the definition of repetition time is pretty unambiguous for most EPI sequences where slice timing matters (DWI, fMRI, resting state). However, the term becomes complicated and vendor specific with some sequences, hence the BIDS terms RepetitionTimeExcitation and RepetitionTimePreparation.
Following up on this now that I have used a pretty recent (July 2022) version of dcm2niix. Here is the json file text.
{
"Modality": "MR",
"MagneticFieldStrength": 3,
"ImagingFrequency": 123.249,
"Manufacturer": "Siemens",
"ManufacturersModelName": "Prisma_fit",
"InstitutionName": "",
"InstitutionalDepartmentName": "Department",
"InstitutionAddress": "",
"DeviceSerialNumber": "",
"StationName": "",
"BodyPartExamined": "HEAD",
"PatientPosition": "HFS",
"ProcedureStepDescription": "",
"SoftwareVersions": "syngo MR E11",
"MRAcquisitionType": "2D",
"SeriesDescription": "nc_epi2d_v2f_Standard_RestingState",
"ProtocolName": "nc_epi2d_v2f_Standard_RestingState",
"ScanningSequence": "RM",
"SequenceVariant": "SP\\OSP",
"ScanOptions": "FS",
"SequenceName": "ep2d_2f2d1",
"ImageType": ["ORIGINAL", "PRIMARY", "M", "ND", "MOSAIC"],
"NonlinearGradientCorrection": false,
"SeriesNumber": 3,
"AcquisitionTime": "",
"AcquisitionNumber": 1,
"SliceThickness": 2.5,
"SpacingBetweenSlices": 3,
"SAR": 0.0978746,
"EchoTime": 0.03,
"RepetitionTime": 0.07,
"FlipAngle": 90,
"PartialFourier": 1,
"BaseResolution": 64,
"ShimSetting": [
-176,
-1782,
1003,
465,
-129,
-177,
-81,
44 ],
"TxRefAmp": 235.123,
"PhaseResolution": 1,
"PhaseOversampling": 0.12,
"ReceiveCoilName": "HeadNeck_64",
"ReceiveCoilActiveElements": "HC1-7",
"PulseSequenceDetails": "%CustomerSeq%\\nc_epi2d_v2f",
"CoilCombinationMethod": "Sum of Squares",
"ConsistencyInfo": "N4_VE11C_LATEST_20160120",
"MatrixCoilMode": "SENSE",
"PercentPhaseFOV": 100,
"PercentSampling": 100,
"PhaseEncodingSteps": 72,
"AcquisitionMatrixPE": 64,
"ReconMatrixPE": 64,
"PixelBandwidth": 2300,
"DwellTime": 3.4e-06,
"PhaseEncodingDirection": "j-",
"SliceTiming": [
0,
0.07,
0.14,
0.21,
0.28,
0.35,
0.42,
0.49,
0.56,
0.63,
0.7,
0.77,
0.84,
0.91,
0.98,
1.05,
1.12,
1.19,
1.26,
1.33,
1.4,
1.47,
1.54,
1.61,
1.68,
1.75,
1.82,
1.89,
1.96,
2.03,
2.1,
2.17,
2.24,
2.31,
2.38,
2.45,
2.52,
2.59,
2.66,
2.73,
2.8,
2.87,
2.94,
3.01,
3.08,
3.15,
3.22,
3.29 ],
"ImageOrientationPatientDICOM": [
1,
0,
0,
0,
1,
0 ],
"ImageOrientationText": "Tra",
"InPlanePhaseEncodingDirectionDICOM": "COL",
"ConversionSoftware": "dcm2niix",
"ConversionSoftwareVersion": "v1.0.20220720"
}
dcm2niix assumes that the DICOM tags are truthful. It looks like the CSA header is reporting the single band reference not the multiband slice times. This reminds me of a historical issues with the [CMRR}(Slice timing info unfolded for the first DICOM file in a MB time series · Issue #29 · CMRR-C2P/MB · GitHub) sequences reported here. I would contact the sequence developer, I am unfmailiar with nc_epi2d_v2f as the CMRR sequences list something like cmrr_mbep2d_bold. Again, this is a limitation of your DICOMs, not dcm2niix.
One trick might be to separate the final volume of the series in isolation from the others. If the issue is similar to the CMRR images, only the first instances recorded incorrect slice times. You can use the renaming dcm2niix -r y /path/to/dicoms to rename your data by instance number.
1 Like
@neurolabusc : I renamed the data by instance number as you suggest above. Doesn’t look like incorrect slice timing report is the issue here. The dicom header for later instance numbers also report the same slice timings, and the same TR. The sequence actually does define 70 ms as the TR based on the sequence pdf file, which is also the value in the (0018, 0080) dicom tag. The situation appears similar to one described in Wrong pixdim[4] (volume acquisition time) stored for 3D fMRIs? · Issue #369 · rordenlab/dcm2niix · GitHub , the difference being this is Siemens, not Philips. 70 ms x 48 slices x # of volumes exactly matches the total acquisition time, so time to acquire one slice is being reported as TR.
dcm2niix assumes that the DICOM images are truthful. If both the PDF and DICOM 0018,0080 report 70ms, dcm2niix is reporting what it has been told. Something very odd is going on here. I would suggest you work with the Siemens Research Collaboration Manager associated with the instrument to resolve this.