Tcksift: only 1 tracks read from input file

Thanks, Rob.

I checked tckstats again with some other subjects as well. The SIFTed subjects had exactly 25M tracks compared to the non-SIFTed ones which lacked a fraction from 25M, either tiny or a lot (I encountered a subject that had 8M tracts, with header implying 25M tracts). I’m currently curious about the reason for this lower count of fibers written on the disc considering that there were no errors during tckgen and enough storage; maybe HDD-related issues (written on NTFS format).

I think the problem is due to the mismatch or maybe tcksift cannot read from the disc, changing the header to the exact number of tracts (not to “one”) may solve the problem. Of note, the subjects with lot less than 25M tracts (e.g., 8M) require re-tractography, after changing their directory.

I’ll update this thread for any future issues.

Bests,
Amir

Okay, sounds like you’ve got a nice non-reproducible problem on your hands :grimacing:

One final thing to add if you’re intending to poke and prod further. When an MRtrix3 command is reading streamlines data from a .tck file, it will cease reading data and report that there are no streamlines left as soon as it encounters an end-of-file flag (Infinity as a floating-point number). We use this to provide guarantees about self-consistency of files, by writing new track data beyond the flag and only once that process is completed changing the old flag to instead be a between-track delimiter. So there’s a chance for there to be a difference between “the number of streamlines that MRtrix3 can read from the file” and “the number of streamlines for which there are vertex data in the file”. If there’s an EOF flag somewhere in the middle of the file that shouldn’t be there—regardless of how it got there / why it wasn’t erased—that could be informative. The file size should give some sense of whether the reported readable streamline count may or may not reflect the full contents of the file; better would be to hijack the C++ code to report the file offset at the location of the EOF flag, and compare that to the file size / look at the contents there in a Hex editor.

Rob