support nifti-2 files

[benkay86]

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.

[Enet4]

Hello! Thank you for your interest in nifti-rs.

NIFTI-2 support would be nice to have, and there may well be a way to make the format work without fragmenting the API. I never worked on it personally because, despite its existence since 2011, I had never encountered data sets in NIFTI-2 in practice during my PhD work. They were always in NIfTI-1.1. I am also not sure if other stakeholders have stumbled upon or had considered using NIFTI-2 files (CC @nilgoyette).

Nevertheless, I would be happy to accept pull requests and provide any eventual guidance towards this feature!

[nilgoyette]

I asked my colleagues who actually work with patient data and they both told me that they never saw a NIFTI-2 file.

Rare or not, this is definitely a nice-to-have. feature in nifti-rs.

[benkay86]

Finally had the opportunity to work on this. I agree NIFTI-1 is more common coming off scanners, but NIFTI-2 is now ubiquitous in large neuroimaging research datasets like the Adolescent Brain Cognitive Development Study. It appears to be the default for research-oriented tools like nibabel. I think #90 introduces an API that makes sense for new users of nifti-rs, but it is not backwards compatible with the current API. Feedback is welcome.