You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
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).
Additional feature request: tckconvert to receive same header modification command-line options as mrconvert, in particular to enable anonymisation following #1603.
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.
(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.
Activity
dchristiaens commentedon Dec 7, 2015
I'm all for! As a matter of fact, I had already implemented the
tckconvertcommand 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 commentedon Apr 11, 2016
Also implement support for .trk format.
Lestropie commentedon Jul 9, 2016
As discussed in #480: Also implement piping of streamlines data.
Lestropie commentedon Jun 5, 2017
Bumping this since there's a bit of interest. I'll hopefully get to it as part of my fixel TWI development stuff.
Lestropie commentedon Feb 4, 2019
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 commentedon Mar 1, 2020
Additional feature request:
tckconvertto receive same header modification command-line options asmrconvert, in particular to enable anonymisation following #1603.Lestropie commentedon Nov 17, 2020
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.
Lestropie commentedon May 10, 2023
Desired formats:
.tck(obviously).trk(TrackVis).fib(DSI Studio; though some documentation indicates that it stores fixel data also...)Note that if available, using the piping handler in conjunction with
tckeditto 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
.trkand TRX give the ability to store any number of:.tsffiles for this purpose).npyas of Npy file format support & half-precision floating-point #2437).trkstores 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
tckconvertwould not be added here, since they involve explicit cylinder construction and/or are 3D-printing-specific.