@lassoan the NIfTI format was designed for MRI scans prior to the advent of multi-band. It describes the relative timing of the 2D slices that are stacked to form a 4D volume.
- The timing between volumes is always fixed (TR = pixdim[4]). This makes sense for MRI, as variable TR impacts the image contrast. However, I think @fedorov would like to describe variable times between volumes for the CT modality. This is a useful feature, but not supported by NIfTI.
- The NIfTI format only describes ascending, descending, odd-first interleaved and even-first interleaved patterns of 2D slices. This is sufficient to allow slice time correction for single-band MRI. However, it can not describe multi-band sequences, e.g. with a 32-slice volume and MB=4, a total of 8 readouts are performed each with 4 aliased slices (though one could argue that MB allows very short TRs, so the slice-timing error is very small allowing the temporal derivative to soak up variability and allowing one to ignore slice time correction).
- Tools like dcm2niix can create a BIDS format JSON text file with the
SliceTiming tag that independently does describe the time of each slice in a volume. Therefore, this can describe multi band. However, it still does not provide a mechanism to describe variable time between the 3D volumes that compose a 4D series.
Since the NIfTI format can not support variable timing between volumes, perhaps NRRD could be formally extended. It appears the Slicer has informally introduced the NRRD tag MultiVolume.FrameLabels: MultiVolume.FrameLabels:=0.0,4270.0,8541.0,12812.0,.... If some scheme like this could be adopted as part of the NRRD specification, it could solve @fedorov’s issue (though I realize he is also advocating that DICOM might be a flexible format to handle this situation).
By the way, the full description of NIfTI slice timing support is embedded in the NIfTI header:
slice_duration = If this is positive, AND if slice_dim is nonzero,
indicates the amount of time used to acquire 1 slice.
slice_duration*dim[slice_dim] can be less than pixdim[4]
with a clustered acquisition method, for example.
slice_code = If this is nonzero, AND if slice_dim is nonzero, AND
if slice_duration is positive, indicates the timing
pattern of the slice acquisition. The following codes
are defined:
NIFTI_SLICE_SEQ_INC == sequential increasing
NIFTI_SLICE_SEQ_DEC == sequential decreasing
NIFTI_SLICE_ALT_INC == alternating increasing
NIFTI_SLICE_ALT_DEC == alternating decreasing
NIFTI_SLICE_ALT_INC2 == alternating increasing #2
NIFTI_SLICE_ALT_DEC2 == alternating decreasing #2
{ slice_start } = Indicates the start and end of the slice acquisition
{ slice_end } = pattern, when slice_code is nonzero. These values
are present to allow for the possible addition of
"padded" slices at either end of the volume, which
don't fit into the slice timing pattern. If there
are no padding slices, then slice_start=0 and
slice_end=dim[slice_dim]-1 are the correct values.
For these values to be meaningful, slice_start must
be non-negative and slice_end must be greater than
slice_start. Otherwise, they should be ignored.
Personally, I think different formats fill different niches: NIfTI/NRRD are very simple and fast to parse. They lend themselves to datascientists and developers who want to tools that can quickly read and write tools with simple I/O. The DICOM format is very flexible, but extremely complex, compounded by the fact that different vendors have interpreted the standard differently. Ideally, it would be great if the DICOM standard could describe a “core” usage, similar to how one can use the legacy OpenGL or the streamlined “ES” and “Core” specifications. Since the “Core” features are a subset of the full specification, systems would be backward compatible. However, new enhanced files that followed the core pattern would be much faster to parse (in particular if group lengths were mandatory). Until such a time, DICOM is extremely flexible but unwieldy for many projects. While I respect @Fedorov and David Clunie’s feeling that DICOM should be THE medical imaging format, I think the success of NIfTI and NRRD reflect a Darwinian selection. Different species have developed that are each adapted to their niche. If we really want to see wider adoption of DICOM in tools, we need to explore how DICOM can evolve to succeed in more environments (simplified core specification, core validator, etc.).