Skip to content

Track files: Implement file format handlers #411

Open

Description

@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.

Activity

  1. dchristiaens commented on Dec 7, 2015

    @dchristiaens
    Member

    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.

  2. Lestropie commented on Apr 11, 2016

    @Lestropie
    MemberAuthor

    Also implement support for .trk format.

  3. Lestropie commented on Jul 9, 2016

    @Lestropie
    MemberAuthor

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

  4. Lestropie commented on Jun 5, 2017

    @Lestropie
    MemberAuthor

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

  5. added this to the 3.0_RC4 release milestone on Jan 31, 2019
  6. Lestropie commented on Feb 4, 2019

    @Lestropie
    MemberAuthor

    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).

  7. Lestropie commented on Mar 1, 2020

    @Lestropie
    MemberAuthor

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

  8. Lestropie commented on Nov 17, 2020

    @Lestropie
    MemberAuthor

    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 tee-ar-ex/trx-python#1.

  9. removed this from the 3.1.0 updates milestone on Apr 19, 2023
  10. Lestropie commented on May 10, 2023

    @Lestropie
    MemberAuthor

    Desired formats:

    • .tck (obviously)
    • VTK as polylines, either ASCIII or binary
    • VTK as newer unofficial format (ENH tckconvert: Support newer VTK 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 Npy file format support & half-precision floating-point #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 ENH Support TRX format #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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions