I’m working on refactoring the way model hierarchies are handled in Slicer, which ultimately means getting rid of the current concept of model hierarchies altogether.
In the process I bumped into the Fibers feature in the Models module. When the user clicks the Include Fibers checkbox, three tabs appear: Line, Tube, Glyph. It seems to do two things: show the fiber bundle nodes in the tree, and turn on visibility of the nodes of the type of the active tab.
Does anyone know
Exactly how this feature should work?
a. And whther it works correctly in the latest nightly?
If this feature is needed, or what are the expectations about this in 5.0?
Thanks a lot!
@pieper@fedorov@jcfr@lassoan (I couldn’t find Lauren’s user name here but I think she should definitely chime in)
I really have no experience with anything fiber, so cannot comment on the actual issue, but Lauren is @ljod, and I am 110% sure @rkikinis will want to comment on this!
This is a holdover from when SlicerDMRI was extracted from the core and moved to the extension. At the time I guess people couldn’t find a good way to make the model hierarchies and Models module extensible so some of the fiberbundle-specific code remained in the Models module. I wasn’t directly involved, but I understand that the fiberbundle infrstructure is still needed for the dmri extension. On the other hand there’s also a Tractography Display module, so maybe the Models module options are no longer needed. I agree @ljod is the best to comment.
The tractography use case tends to really stress the infrastructure since it may generate thousands of fiber bundles grouped into dozen or hundreds of clusters. We wouldn’t want to break existing functionality unless there is a viable alternative.
It’s great that you are looking into this @cpinter and maybe there’s a way to get have a fresh approach that works better than the model hierarchies. Do you think the subject hierarchy can scale to handle such large numbers of nodes?
Just to avoid any confusion, just the model hierarchy nodes and the related old code will disappear, not the option of arranging models into hierarchies It will be taken care of by subject hierarchy, and instead of creating Model Hierarchy nodes, you create Folder items.
A possibility what this feature chould convert into are subject hierarchy options (i.e. in the right-click menu) in the tractography plugin that offers filtering for certain nodes, and/or changing visibility of all nodes of certain types (since the original features seem to do these two things).
Yes, SH is faster than SceneModel. So if it used to work with that, then it will work with SH.
Part of the motivation for this change is better handling of atlases (I’m doing it in terms of the OpenAnatomy project).
Hi! Yes we actively use the fiber hierarchies in all our work with fiber bundle atlases. We definitely need this functionality moving forward. Before Alex implemented this functionality as part of my U01, is was virtually impossible to visualize the results of applying our atlases to subject data. It’s great if large numbers of nodes can become more practical since that is a challenge for us.
We don’t have this functionality currently in tractography display, just in the Models module.
I will need to re-implement these features, and it would be great to get them right for the first try. If you could define exactly what your current needs are (even if slightly or very different from that of the past), then I could provide a solution that accommodates more the actual situation.
I know you have a very different “upcoming project” So if you don’t have the time, then I’ll do something simple that covers the original setup (for example what I described above). I will get to it on Thursday probably.
It will be taken care of by subject hierarchy, and instead of creating Model Hierarchy nodes, you create Folder items.