Track files: Implement file format handlers

[Lestropie]

Much like is done for image files, it should be possible to identify different types of track data storage based on the file extension, and have the Tractography::Reader and Writer classes call relevant handler functions to extract / write data from/to the Tractography::Streamline class.

This would allow any streamlines-handling command to handle streamlines data stored in any format, and may also allow the tckconvert command functionality to be encapsulated within the tckedit command.

Ideally this should also allow the Writer class to use buffered writeback for any format.

As first mentioned in #216.

[dchristiaens]

I'm all for! As a matter of fact, I had already implemented the tckconvert command as a bunch of Reader/Writer classes, which should be more or less ready to go in the library. The reason I didn't do so at the time, was mainly because I did not yet implement a VTKReader class. I've written code for that in python a few years ago, to import tracks from MITK-Diffusion, but found it tricky to make it compatible with different software packages.

More importantly, reading and writing to a VTK file requires to keep its contents in RAM, making them very unsuited for streamline tracking or filtering of large datasets. Therefore, I would still advise users to stick to .tck, even though it would be nice to support other formats transparently.

[Lestropie]

Also implement support for .trk format.

[Lestropie]

As discussed in #480: Also implement piping of streamlines data.

[Lestropie]

Bumping this since there's a bit of interest. I'll hopefully get to it as part of my fixel TWI development stuff.

[Lestropie]

This is going to require quite a lot of refactoring. I'd rather remove the RC4 milestone from this, and instead address it as part of my fixel TWI updates (second major update trailing #1543).

[Lestropie]

Additional feature request: tckconvert to receive same header modification command-line options as mrconvert, in particular to enable anonymisation following #1603.

[Lestropie]

Note that any modifications in this respect should be made with the foresight of the most general case of streamlines data storage; current candidate for a new community-driven format is frheault/tractography_file_format#1.

[Lestropie]

Desired formats:

• [ ] .tck (obviously)
• [ ] VTK as polylines, either ASCIII or binary
• [ ] VTK as newer unofficial format (#2596)
• [ ] ASCII data (only one streamline per file)
• [ ] Raw data through Unix pipe
• [ ] .trk (TrackVis)
• [ ] TRX, ideally whether as directory or as tarball
• [ ] (optional) TinyTrack (TT) (DSI Studio)
• [ ] (optional) .fib (DSI Studio; though some documentation indicates that it stores fixel data also...)

Note that if available, using the piping handler in conjunction with tckedit to concatenate tractography files may be preferable to the solution proposed in #1571, which is to have a text file containing the paths to a list of tractography files (and in the context of this issue that would need to be its own handler). But I'm not against the latter if there are other benefits to such.

Additional layer of complexity: Both .trk and TRX give the ability to store any number of:

• Scalar values per vertex (we use separate .tsf files for this purpose)
• Any number of scalar values per streamline (we use ASCII files for this purpose, though will also be able to use .npy as of #2437) .trk stores all of this within a single binary file; TRX stores them across different files but with a stringently-enforced filesystem structure / naming convention. As mused in #2241 not clear exactly how to deal with this in the context of piping streamline data down a queue.

Some formats currently handled in tckconvert would not be added here, since they involve explicit cylinder construction and/or are 3D-printing-specific.