Community file-format technological survey discussion

General goals

• Uniformization across tools
• Allowing features needed by the fields (from trk, tck or new one)
• Conceptually simpler (Simplicity)
• Less memory AND hard drive hungry
• General robustness
• Load/save efficiency/speed
• Independence/standalone
• Extensibility

What is 'supported' by the memmap implementation?

• Agreement on the coordinates system (RASMM) [x]
• Random-access support with minimal upfront IO [x]
• Support data streaming and on-the-fly saving [x]
• Minimalistic header [x]
• Ability to store (sparse) groups [x]
• Ability to store None, one or more additional metadata [x]
• Self-explanatory [x]
• Self-coherent / strict checks [-] (depends on the implementation)
• Compression [-] (only zip_deflate)
• GPU compatibility [-] (Array+offsets are compatible 'enough' with VTK/OpenGL)
• “Easy” to implement with basic libraries (in C++, python, matlab, etc.) [x]
• Parallel-friendly for saving (per process on-the-fly saving) [ ] (Not investigated, likely depends on implementation)

(Initial thread: https://github.com/nipy/nibabel/issues/942)

Start by reviewing the initial thread in nibabel issue #942 and the memmap implementation referenced in this discussion. Identify which file-format goals are already supported and which remain unresolved. The work is complete when the community agrees on the survey findings and a concrete direction for the format.