I acquired fMRI data using a Philips scanner and used dcm2niix to convert dicom to nifti. However, I cannot find anywhere in the json file where the number of slices is stored. Is there a way to retrieve this information?
The BIDS sidecar stores values that are not present in the NIfTI header. Having data in both locations would require a tool to decide precedence when the values disagree. The number of slices is the 3rd dimension in the NIfTI header, aka dim3. In the example below, there are 215 slices.
For 2D EPI data where the vendor was kind enough to provide slice times, you can also look at the number of elements in the BIDS field SliceTiming. There will be one entry for every slice in your image.
$fslhd spm152.nii.gz
filename spm152.nii.gz
sizeof_hdr 348
data_type UINT8
dim0 3
dim1 207
dim2 256
dim3 215
dim4 1
dim5 1
dim6 1
dim7 1
...
For completeness, there is typically one redundant value between BIDS and NIfTI: the BIDS tag RepetitionTime is often the same as the NIfTI tag pixdim[4]. Since many tools (e.g. SPM12) purge pixdim[4], I presume most tools give precedence to the BIDS tag.
Thank you @Chris_Rorden . I’ll do as you suggested regarding the number of slices.
One more thing though, I’m having the same problem as many, that dcm2niix has no way of figuring out the slice acquisition order from Philips scanners. I read another post here in which you suggested following the steps in this page, but I cannot find an entry for Mode in my nifti header (using im = nibabel.load('im.nii.gz') and print(im.header))
Is there a specific tag I could retrieve from the dicoms that helps inferring slice order?
This is a limitation of your DICOM images, not my software. See the Missing Information section for the dcm2niix Philips page. Please lobby your Philips Research Collaboration Manager to have these details included in future releases of their software. You can determine the Philips acquisition mode by looking at the sequence on your Philips console. It is not stored in the header. Be aware that slice order for multi-band sequences are not intuitive (though the very short TRs associated with multi-band dramatically diminish the slice time error).
When all else fails, you can pragmatically determine slice order by having a participant rapidly rotating their head to one side (e.g. the first motion of a “no” gesture) during a single volume (add a delay after each volume, so the participant can identify the start of each volume). This is described here.