Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
tcksample: Redesign #480
I'm intending to redesign how this command / operation is used / performed, but want to make sure that I'm not removing any used functionalities by doing so.
So here's what I'm thinking:
What I'm stuck on is the current
Well, in the previous MRtrix 0.2 version, this command was split into two:
Looking at what you're proposing, I can see the value-add of getting summary per-streamline values, and to some extent the precise sampling (just not convinced it would make a huge difference in practice). I can see that track resampling to a different step size would fit neatly into
I guess what I'm puzzled by is the suggestion that
Anyway, if you really feel the 'wacky resampling' aspect needs to be split off from
I agree that you almost certainly don't need the tracks; no argument there. The command as it stands works because the two functionalities can more-or-less live side-by-side. But as soon as you try to expand features, it starts to get confusing as to what options apply to what, and what order things are done in (e.g. there's already explicit instructions required for the
By splitting, the order of operations becomes explicit, and for new options / functionalities it's clear as to what they apply. In the future, I'd also like to have what I'm currently calling
The intermediate track file could potentially be dealt with once track format handlers are in place by enabling track file piping (though not sure if tmpfs disk space will become an issue here). But given the scope of what can go wrong with processes like these, exacerbated by non-linear registrations etc., personally I prefer the default being to generate the intermediate track file that a user can choose to ignore, rather than not generating it (which implies that it doesn't need checking).
Ah yes, I'd forgotten about the
Yes, as soon as you add other possibility for the resampling, this makes sense. Sampling along an exemplar sounds like a neat idea.
Yes, it's becoming clear that being able to pipe streamlines would help with a lot of these issues. The tmpfs disk space is a non-issue here by the way, since in this case I'd advocate streaming the data directly through the pipe - no need to write to a temporary file. This would allow the pipeline to run on memory-constrained system without any issues. The reason why it would be possible in this case is because the data genuinely comes out as a stream - as opposed to images that require random access while either command is accessing it. This may imply that methods like SIFT would not be compatible with piping? But then it's probably best to require users to explicitly store the tracks in these cases anyway, given how large the files are going to be - anything else would probably entail higher RAM usage during execution one way or the other...
No worries, make more sense now anyway...
OK cool. I do like the idea of streamed piping, as long as it works with multiple concatenated pipes, and I suppose you might need some form of progressbar suppression (though with the progress percentage on the left now, maybe you'd get a cool flickering superposition of progress messages?).
Anyone got any thoughts on command naming?
Correct: the track file needs to be read twice (once to build the streamline fixel visitations, again to generate the output track file). I suppose the
What do you mean by 'multiple concatenated pipes'? I can't see any issues with multiple sequential stages, if that's what you're asking? Much trickier if you want to support multiple pipes into the same command though, although that's a very rarely used feature which is unique to MRtrix anyway... However:
Yes, the output will probably not look great in this case... There is always the
[Edited due to mobile madness]
Seems a bit overkill to me, when this is probably a special case... (?) Might be simpler/cleaner just to check whether the filename is
Yeah, that's just me derping. No reason why the terminal wouldn't handle stdin/stdout correctly for each command in multiple sequential stages. Just trying to fully wrap my head around this, since track data piping might help with the command role / naming issues here so thinking about attacking #411 and including this.
If we had track data piping, I could remove these functionalities from
Yeah, or just a 2-line helper function somewhere for commands to check it and give a standardised error.