66 releases

0.28.0 Oct 20, 2023
0.27.0 Dec 9, 2022
0.26.0 Dec 6, 2022
0.23.0 Nov 15, 2022
0.3.5 Dec 27, 2017

#224 in Data structures

Download history 17/week @ 2024-02-16 27/week @ 2024-02-23 12/week @ 2024-03-01 2/week @ 2024-03-08

58 downloads per month

BSD-2-Clause

60KB
1.5K SLoC

trk-io   Latest Version Coverage Build Status dependency status

trk-io implements a TrackVis (.trk) reader and writer.

Highlights

  • Can read and write TrackVis files. Handles affine transformation as nibabel.streamlines and MI-Brain would.
  • Reading and writing is tested as much as in nibabel.streamlines.
  • Can optionally use the nifti-rs crate, which can then be used to create a trk header from a NiftiHeader, like you would do in nibabel
  • Reader can read all streamlines at once or can be used as a generator.
  • Scalars and properties are supported when reading and writing trk. You can find some examples in trk_color.rs.
  • Write all at once or streamline per streamline.
  • Follows nibabel.streamlines architecture (all 3D points are in a single Vec![Point3D]). Currently, this is only useful for performance, but it may lead to easier changes when and if we support BLAS.
  • Handles endianness.
  • Some useful tools are coded in examples/*.rs. It's a good way to learn how to use this library.

Examples

// Read complete streamlines to memory
let tractogram = Reader::new("bundle.trk").unwrap().read_all();
for streamline in &tractogram.streamlines {
    println!("Nb points: {}", streamline.len());
    for point in streamline {
        println!("{}", point);
    }
}
// Simple read/write. Using a generator, so it will load only
// one streamline in memory.
let reader = Reader::new("full_brain.trk").unwrap();
let mut writer = Writer::new(
    "copy.trk", Some(reader.header.clone()));
for tractogram_item in reader.into_iter() {
    // tractogram_item is a TractogramItem, which is a tuple of
    // (streamline, scalars, properties).
    writer.write(tractogram_item);
}
// The new file will be completed only at the end of the scope. The
// 'n_count' field is written in the destructor because we don't
// know how many streamlines the user will write.

Roadmap

There's still a lot of work to do but it should work perfectly for simple use cases. In particular, future versions should be able to:

  • Support TCK reading/writing
  • Create some binary tools using this lib, e.g. show_affine, count_tracks, pruning, strip_info, etc.
  • Support for ops.Range, e.g. streamlines[0..10]

Your help is much appreciated. Consider filing an issue in case something is missing for your use case to work. Pull requests are also welcome.

Dependencies

~3.5MB
~73K SLoC