Unsure about why previous two versions of dcm2niix give different values for slicetiming field of GE dataset

, ,
1

It looks like the last Fall and Spring releases of dcm2niix fill the slicetiming field in the jsons associated with images from a GE scanner with different values.

Fall Release "SliceTiming": [ 0.145455, 0.509091, 0.0727273, 0.436364, 0, 0.363636, 0.727273, 0.290909, 0.654545, 0.218182, 0.581818, 0.145455, 0.509091, 0.0727273, 0.436364, 0, 0.363636, 0.727273, 0.290909, 0.654545, 0.218182, 0.581818, 0.145455, 0.509091, 0.0727273, 0.436364, 0, 0.363636, 0.727273, 0.290909, 0.654545, 0.218182, 0.581818, 0.145455, 0.509091, 0.0727273, 0.436364, 0, 0.363636, 0.727273, 0.290909, 0.654545, 0.218182, 0.581818, 0.145455, 0.509091, 0.0727273, 0.436364, 0, 0.363636, 0.727273, 0.290909, 0.654545, 0.218182, 0.581818, 0.145455, 0.509091, 0.0727273, 0.436364, 0 ]
Spring Release "SliceTiming": [ 0.72, 0.32, 0.64, 0.24, 0.56, 0.16, 0.48, 0.08, 0.4, 0, 0.72, 0.32, 0.64, 0.24, 0.56, 0.16, 0.48, 0.08, 0.4, 0, 0.72, 0.32, 0.64, 0.24, 0.56, 0.16, 0.48, 0.08, 0.4, 0, 0.72, 0.32, 0.64, 0.24, 0.56, 0.16, 0.48, 0.08, 0.4, 0, 0.72, 0.32, 0.64, 0.24, 0.56, 0.16, 0.48, 0.08, 0.4, 0, 0.72, 0.32, 0.64, 0.24, 0.56, 0.16, 0.48, 0.08, 0.4, 0 ]

Unfortunately, it’s not currently clear to me which values are correct. I’m also not seeing anything obvious in dcm2niix's github repository or release notes indicating what would have caused this difference. Though, there is this issue https://github.com/rordenlab/dcm2niix/issues/544, which might apply to these data (i.e., number of slices divided by multiband factor produces an even number). If that’s the case, would it be correct to trust the outputs from the Fall release?

Fields that are shared by both outputs copied below

{
	"Modality": "MR",
	"MagneticFieldStrength": 3,
	"ImagingFrequency": 127.779,
	"Manufacturer": "GE",
	"PulseSequenceName": "epi",
	"InternalPulseSequenceName": "EPI",
	"ManufacturersModelName": "DISCOVERY MR750",
	"BodyPartExamined": "BRAIN",
	"PatientPosition": "HFS",
	"SoftwareVersions": "27\\LX\\MR Software release:DV26.0_R02_1810.b",
	"MRAcquisitionType": "2D",
	"ScanningSequence": "EP\\RM",
	"SequenceVariant": "NONE",
	"ScanOptions": "SAT_GEMS\\EDR_GEMS\\MP_GEMS\\EPI_GEMS\\HYPERBAND_GEMS\\PFF\\FS",
	"ImageType": ["ORIGINAL", "PRIMARY", "OTHER"],
	"AcquisitionNumber": 1,
	"TriggerDelayTime": 787,
	"SliceThickness": 2.4,
	"SpacingBetweenSlices": 2.4,
	"SAR": 0.175618,
	"EchoTime": 0.03,
	"RepetitionTime": 0.8,
	"FlipAngle": 52,
	"PhaseEncodingPolarityGE": "Flipped",
	"CoilString": "RM:Nova32ch",
	"MultibandAccelerationFactor": 6,
	"PercentPhaseFOV": 100,
	"PercentSampling": 100,
	"AcquisitionMatrixPE": 90,
	"ReconMatrixPE": 90,
	"EffectiveEchoSpacing": 0.000568494,
	"TotalReadoutTime": 0.050596,
	"PixelBandwidth": 5555.56,
	"PhaseEncodingDirection": "j",
	"ImageOrientationPatientDICOM": [
		1,
		-0,
		0,
		-0,
		1,
		0	],
	"InPlanePhaseEncodingDirectionDICOM": "COL",
	"ConversionSoftware": "dcm2niix"
}
2

Following up on this. @Chris_Rorden, would you happen to have an answer for whether one of the two slice timings are accurate?

3

You will want to look at the details and sample code here. As noted there, GE changed the slice order with 27.0 R3 to minimize interference. Further details are here. If your site has signed the GE research master agreement, you should be able to request the official GE document that describes the slice ordering patterns and the rationale behind them.

The core issue is that the user selected an inherently asymmetric multi-band pattern. Methods for making the best of this bad situation have changed with software releases. This issue could have been avoided if the user had specified a recommended slice number. Specifically, 60 slices were acquired with a multi-band of 6. For future acquisitions, you should always ensure that the number of slices divided by the multi band factor is an odd number. Therefore, for the MB=6 the number of slices should be in the sequence 6, 18, 30, 42, 54, 66…etc. For further description and citation see here.

You can see the modfications provided by GE engineers here. They were able to identify when the change was made to GE software. They submitted the modification to dcm2niix on Oct 4, 2021
. This was one of the final changes made to the Fall 2021 stable release of dcm2niix.

4

Thank you for the detailed response. This information is very helpful