The nifti-1 file format was finalized in 2007. In 2011, the nifti-2 format was created to support larger data sets. Nifti-2 is now widely-used in the neuroimaging field, and furthermore, it serves as the basis for the CIFTI-2 format.
A decade later, nifti-rs supports nifti-1 but not nifti-2. Attempting to read a nifti-2 file produces a NiftiError::InvalidFormat. This is unfortunate, because nifti-rs is otherwise an excellent library with many advantages over its C/C++ and Python counterparts.
Is there interest in adding nifti-2 support to nifti-rs? The differences between nifti-1 and nifti-2 are not great. See also Anderson Winkler's blog and nifti2.h. There are test data here.
- No new header fields are added
- The types of 30 existing header fields are enlarged (e.g., 32-bit float --> 64-bit double)
- 7 existing header fields that were unused are removed
- The header itself is (obviously) larger
- The header fields are stored in a different order
- The magic string is different
Supporting nifti-2 should therefore not be too difficult, but would require some deliberate changes to the API. Since the two headers are so similar, it might make sense to create concrete Nifti1Header and Nifti2Header types, and make NiftiHeader an enum over both types with getter methods to extract the values of shared fields as the larger type. This would let users who are reading an image not have to care about the underlying version (nifti1 vs nifti2). Users writing an image would still have to manually populate the header fields for whichever version they intend to write out.
enum NiftiHeader {
Nifti1Header(Nifti1Header),
Nifti2Header(Nifti2Header),
}
impl NiftiHeader {
pub fn slice_duration(&self) -> f64 {
match *self {
// promote nifti1 type to size of larger nifti2 type
Nifti1Header(ref header) => header.slice_duration as f64,
Nifti2Header(ref header) => header.slice_duration,
}
}
}
I welcome feedback about the API changes and, although my time is limited, I would be happy to submit incremental pull requests against a nifti-2 branch.
The nifti-1 file format was finalized in 2007. In 2011, the nifti-2 format was created to support larger data sets. Nifti-2 is now widely-used in the neuroimaging field, and furthermore, it serves as the basis for the CIFTI-2 format.
A decade later, nifti-rs supports nifti-1 but not nifti-2. Attempting to read a nifti-2 file produces a
NiftiError::InvalidFormat. This is unfortunate, because nifti-rs is otherwise an excellent library with many advantages over its C/C++ and Python counterparts.Is there interest in adding nifti-2 support to nifti-rs? The differences between nifti-1 and nifti-2 are not great. See also Anderson Winkler's blog and nifti2.h. There are test data here.
Supporting nifti-2 should therefore not be too difficult, but would require some deliberate changes to the API. Since the two headers are so similar, it might make sense to create concrete
Nifti1HeaderandNifti2Headertypes, and makeNiftiHeaderanenumover both types with getter methods to extract the values of shared fields as the larger type. This would let users who are reading an image not have to care about the underlying version (nifti1 vs nifti2). Users writing an image would still have to manually populate the header fields for whichever version they intend to write out.I welcome feedback about the API changes and, although my time is limited, I would be happy to submit incremental pull requests against a nifti-2 branch.