node-independent means of visualization for specific voxels

[orenshatz]

Nodes are specifically dedicated entities to the annotation of neurites, in the context of trees. Do we want to have different "kinds" of trees for simply choosing certain voxels in the datasets? Or another kind of entity which isn't a node, because it definitely isn't necessarily part of a tree?

[Optiligence]

Trees are only agglomerates (things in the annotation.xml) of nodes. Nodes are only representations of voxels with some additional properties like radius and connectivity (which actually isn’t a node property in the file) I’d still use nodes, with properties indicating their purpose. In the end you want to iterate over everything you want to render and not over different collections.

[orenshatz]

The difficulty is that any existing neurite-associated code iterating on nodes would have to be adjusted to ignore nodes of non-neurite property.

[my-tien]

I guess such a tree would be in another skeletonizer, not in the "neurite" skeleton.

[orenshatz]

But if there is currently a code that traverses all nodes/trees, then this code is unaware of the fact that a node might not belong to a "neurite" skeleton. Because so far all nodes were part of an annotated neurite.

[my-tien]

No, what I mean is a new skeletonizer instance. It would be a "meta" skeletonizer with its own first tree and first node.

[orenshatz]

Okay, that's reasonable. The question is whether there is currently a hardcoded reference from node-related code to a singleton skeletonizer, or we can simply create as many meta skeletonizers as we wish. Mind you, we're currently discussing the runtime environment, while Norbert answered above on the implementation of persistency.