@lassoan, thanks for keeping this moving.
I’d vote for the name CppNrrd. Also a new toplevel organization make sense (NrrdTools is good).
I’d also vote for starting with a very specific conformance statement of which nrrd use cases will be supported, and have tests and example data for each of them.
Off the top of my head, I’d suggest the new C++ implementation need to support at least the following features at least in order to be viable replacement for the current library:
- scalar/vector/tensor volumes, 2D, 3D, 3D+t
- dwi/dti extensions (gradient tables, measurement frames…)
- .nhdr and data files
This shouldn’t be hard since for the most part they just expose the raw buffers and headers. Adding parallel compression and other new features would be great.
Just to note: replacing hard to maintain legacy nrrd code makes sense, and nrrd is a good lightweight option in many purposes, but personally I’ll put more effort into better DICOM support for many of the same use cases.