By design, the BIDS JSON file contains information that is not found in the NIfTI header. This removes redundancy and the need to resolve conflicts in between two sources of data.
- The best way to resolve this is to convert your DICOM images using a modern tool like dcm2niix or dicm2nii. If this fails, you will want to look at the PDF file for your sequence, here is an example for SIemens.
- The
SliceTimingtag should have one entry for each slice in your 3D volume. If you trust that the NIfTI header specification ofslice_name alternating_increasingis accurate, than this image does not have multi-band, which seems reasonable considering the number of slices, and TR (e.g. a modern multi-band sequence would acquire more, thinner slices in the same time). With these assumptions, you could setSliceTimingusing this Matlab script
slicetime(2.0, 30, true, false) - You may have to guess regarding
ParallelReductionFactorInPlane. I am not sure many processing tools use this. These techniques (e.g. GRAPPA, SENSE) reduce spatial distortion and allow faster readout times, at the expense of SNR. Visual inspection for spatial distortions can help here. Given the short TR for the number of slices, I would not be surprised if this used a factor of x2. - Assuming these are axial slices that appear symmetrical when viewed, the
PhaseEncodingDirectionis likelyjorj-. You can tell if the polarity isjorj-by visual inspection of the direction of spatial distortion. This only matters if you have a TOPUP compatible phase reversed spin echo sequence that you are also converting, which seems unlikely given the properties of this data set.
"MultibandAccelerationFactor": 1,
"SliceTiming": [
0.000,
1.000,
0.067,
1.067,
0.133,
1.133,
0.200,
1.200,
0.267,
1.267,
0.333,
1.333,
0.400,
1.400,
0.467,
1.467,
0.533,
1.533,
0.600,
1.600,
0.667,
1.667,
0.733,
1.733,
0.800,
1.800,
0.867,
1.867,
0.933,
1.933 ],