Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reserved key for streamline seed point? #2

Open
Lestropie opened this issue Nov 16, 2020 · 1 comment
Open

Reserved key for streamline seed point? #2

Lestropie opened this issue Nov 16, 2020 · 1 comment

Comments

@Lestropie
Copy link

With MRtrix3 there's been a few requests over the years to have, for streamlines propagated bidirectionally from the seed point, knowledge of which vertex in the output streamline corresponds to the seed location. See e.g. tckmap -output_seeds option (which was at the time the easiest hack to satisfy demands).

In the context of this format, it's a DPS of either a uintX index or a 3.floatXX, depending on whether the seed point itself or an index in the output streamline is provided (theoretically it's possible that in some implementation the precise seed location won't actually be included in the output streamline; in MRtrix3 we guarantee that it's included, but I'm thinking of the most general case).

Primarily the question is whether or not such information should have some form of reserved keyword so that all implementations know where to write it in order to be trivially accessible / interpretable at read time.

@frheault
Copy link
Collaborator

I agree we could have a list of reserved keywords, but it should also come with a small description and specification.
Seeds are definitively on my list too. It would be interesting to see what comes up.

If people have suggestions (and descriptions of use-case) please add it here
https://docs.google.com/document/d/1EVc8n8v6KBgdM31ezHeewYgZLrmun0qKqNRlueQM2aE/edit?usp=sharing

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants