When using the Connnectome tool, what is supposed to happen when setting the Geometry of the node visualisation to overlay?
I was expecting to see coloured labels overlayed on the current slices, but instead I get nothing. Spheres, cubes and meshes work as expected.
Is this a bug, or am I missing the point of the overlay option?
The ‘node overlay’ is something I’ve considered removing a couple of times in the past; partly because it’s a nightmare to manage in the code, partly because it’s slightly ambiguous as to how it should work in conjunction with the main image.
I think you should get something out of it by either:
Switching the main window display mode to volume render. This should push the coloured node image onto the 3D overlay image stack. But I suspect it’ll only work if you change the windowing of the main image to make it disappear; if you fully disable rendering of the main image (e.g. with the ‘M’ key), that will likely bypass the primary shader, which in the case of volume rendering, is also responsible for rendering any overlays.
Switching on ‘crop to slab’, and reducing the thickness of the slab to zero. This should then engage rendering of that node overlay image as a slice. There should also be a little warning icon that pops up next to the node geometry selection UI which, if you hover your mouse over it, warns that the node overlay image will only be visible in this configuration.
Trouble is that if you render this image as a slice regardless, not only may the slice be outside the FoV if you’re hiding the main image and have been viewing things in 3D to that point, but having the node visualisation limited to a slice but edges appearing in full 3D looks plain weird. And trying to render the node overlay using its own independent volume render would not only be a nightmare to manage, but would probably not look as good (and be less consistent with user expectation) than explicitly meshing the parcels.
Am open to any ideas or opinions regarding alternatives for how this could be managed.
I really like the connectome view tool and tried the two option you suggested (with the limitations you mentioned).
Maybe it would be possible to show node names in the visualization itself - that way it would be easier do identify them. Or (and maybe easer to implement): to create an option for manually selecting the nodes in the visualization window (by clicking on it), so that you can identify it on the connectome node list.
I’d like to have both of those features eventually. The primary reason I didn’t implement node name labels within the OpenGL window during initial development of the tool is that the majority of parcellation lookup table files only contain a ‘long’ name for each node: these would clutter the screen pretty quickly. Ideally, abbreviated labels should instead be used here; but to do that, those abbreviations need to be available to the tool in the first place. This started in GitHub issue 373, and evolved into GitHub pull request 511, which should be merged within a week or two. But moving on from that to provide node name overlays, and also the click-for-selection, won’t be tackled until after the official software release.
thanks for your detailed reply! Yes, I have seen “long label names” cluttering up the screen in some other network visualization software (where adding names actually makes it more difficult to identify nodes.) So abbreviations would be a good thing I guess - the freesurfer ROI are pretty standardized anyway.
looking forward to the new release!
@TCsquared For the sake of the argument:
When you say that the freesurfer ROIs are ‘pretty standardized’, is this in reference to a more-or-less ‘consistent’ set of abbreviated node names in the literature, or something provided within FreeSurfer itself? I’ve simply adopted those that @chunhungyeh used in his most recent manuscript, which were in turn drawn from some other manuscript. You can see what’s set to become the new default FreeSurfer connectome LUT file here; let me know if there’s a ‘more standardized’ set elsewhere…
I was referring to the set / names of labels created by freesurfer (which you linked). I am not aware of standardized abbreviations for them, at least there are none in the initial publication (Desikan et al., 2006).
But that’s not mandatory anyway, I guess. The abbreviations in the FreeSurfer connectome LUT file are very reasonable (compared to others I have seen) - however to integrate them into the connectome display might be a lot of work, not sure what happens if you start rotating the connectome in the 3D viewer and all the labels have to move along …
… however to integrate them into the connectome display might be a lot of work, not sure what happens if you start rotating the connectome in the 3D viewer and all the labels have to move along …
Yes, it will be one part cleverness and two parts trial-and-error. I have a few ideas that might make it usable, but it’s inevitable that there will be collisions both between labels, and between a label and other geometry, at various camera positions. I can only do the best I can for the sake of the 3D view; and if it doesn’t perform adequately even in a 2D view for the sake of figure generation, people will have to resort to manual labelling… oh the horror! At least if you have a subset of nodes shown / highlighted it should be possible to find an angle in 3D where it looks OK rather than relying on orthogonal views.