While BIDS validating my data, I got the following message:

You should define ‘SliceTiming’ for this file. If you don’t provide this information slice time correction will not be possible.

Can someone suggest how to do it? The data id from a Philips 3T scanner.



Dear Shilpi

Were you able to resolve this issue, because I am having the same problem…
Also using a Philips scanner.

Any help is much appreciated!


This is a duplicate. I provide some Python code there, though be aware it assumes that multi-band and delay between volumes are not used.

This is a limitation of the DICOM files created by Philips. I would suggest you lobby your Philips Research Collaboration Manager to have this information stored in the DICOM files for future Philips software versions. In the mean time, you will need to BIDS SliceTiming field yourself. You will need to know:

  • Repetition Time (time between start of one volume and start of the next) (BIDS RepetitionTime and NIfTI pixdim[4]).
  • Delay Between Volumes (is there a temporal gap between the acquisition of the last slice of one volume and the first slice of the next).
  • Number of Slices (NIfTI dim[3])
  • Multiband factor
  • Ascending or descending slice order
  • Sequential of interleaved slice order.

If the Phillips scanner data does contain temporal gaps between volumes, and/or the data is multi-band, can the slice-timing information still be reliably determined (using your code or some variation)?

I have extended the Matlab script (below) to also handle temporal gaps between volumes. If you use multi-band (HyperBand for GE users) you will want to work with your vendor Research Collaboration Manager to get the slice acquisition pattern. The very short TR afforded by Multi-Band reduces the slice timing errors, and it is not clear to me if slice timing correction is required as the HRF is sluggish and the temporal derivative can model some of this consistent variance from the canonical HRF.

function slicetime(TRsec, nSlices, isAscending, isSequential, DelayBetweenVolumesSec);
%compute slice timing
% TRsec : sampling rate (TR) in seconds
% nSlices: number of slices in each 3D volume
% isAscending: ascending (true) or descending (false) order
% isSequential: interleaved (false) or sequential (true) order
% DelayBetweenVolumesSec: pause between final slice of volume and start of next
% sliceTime(2.0, 10, true, true); %ascending, sequential
% sliceTime(2.0, 10, false, true); %descending, sequential
% sliceTime(2.0, 10, true, false); %ascending, interleaved
% sliceTime(2.0, 10, false, false); %descending, interleaved
% sliceTime(3.0, 10, true, true, 1.0); %ascending, sequential, sparse

if ~exist('DelayBetweenVolumesSec', 'var')
    DelayBetweenVolumesSec = 0; %continuous acquisition

TA = (TRsec - DelayBetweenVolumesSec) / nSlices; %assumes no temporal gap between volumes
bidsSliceTiming=[0:TA:TRsec-TA]; %ascending
if ~isAscending %descending
   bidsSliceTiming = flip(bidsSliceTiming);
if ~isSequential %interleaved
    if ~mod(nSlices,2)
        fprintf('Timings for Philips or GE. Siemens volume with even number of slices differs https://www.mccauslandcenter.sc.edu/crnl/tools/stc)\n');
    order = [1:2:nSlices 2:2:nSlices];
    bidsSliceTiming(order) = bidsSliceTiming;
%report results
fprintf('	"SliceTiming": [\n');
for i = 1 : nSlices
    fprintf('		%.3f', bidsSliceTiming(i));
    if (i < nSlices)
        fprintf('	],\n');

Thank you so much for your answers and for the code!
I was not aware that this had already been discussed, my apologies for that.

Our images are taken using multiband with a factor 2, 60 slices, TR = 2s, ascending order.
I learned from discussion with the MRI technician that for our scanner this meant that scans 1 and 31 were taken at the same time, 2 & 32 etc. So how I understand it that means that the interval between volumes is 2/30 (0.066666) with the last 30 volumes sequentially taken at the same time as the first 30 volumes. I don’t know if multiband always works like this on Philips scanners, but maybe this is useful for someone.

@VictorM you may want to consider 58 or 62 slices rather than 60 with multi band 2. Sounds like Philips uses a simple pattern, you can always validate the pattern with this with a simple head rotation experiment.

1 Like

I have released a new version of dcm2niix (v1.0.20201102). It should automatically populate the BIDS SliceTiming tag for GE DICOM images. Validation datasets and minimal C code is provided in a public repository. Brice Fernandez and Jaemin Shin from GE provided sample images and insight. The solution should work with all popular fMRI sequences (interleaved, sequential, multi-band, ascending, descending, sparse). Slice times are generated for gradient echo but not spin echo sequences (as GE diffusion slice orders reportedly differ).

This latest version should provide robust slice timing reporting for GE and Siemens equipment. Philips DICOM images do not record the required information to infer slice timing. This reflects a limitation of Philips images, not dcm2niix.