Connectome tool #283
Connectome tool #283
Conversation
Mesh class now supports both 3-vertex and 4-vertex polygons. Note however that GL_QUADS is depreciated as it turns out, so this functionality will likely never be used...
This function takes as input a mask image, and produces a triangular mesh representing the surface of the mask. A pair of triangles is generated at every voxel face where a voxel with value 1 touches a voxel with value 0.
Binary receives as input a mask image, and outputs a mesh in .vtk format.
Currently just adds itself to the list of tools, and has a couple of non-working buttons.
Can now read and write from binary and ASCII data in both VTK and STL formats.
Still nothing drawn though...
This class deals with formation of a GL buffer and neatens the coding interface by hiding the GLuint identifier from the programmer; but it works on index buffers, i.e. data where vertex indices are stored.
This new code structure will allow access to the LUT import functionality within the mrview connectome toolbar.
Allows for lookup tables of different formats to be imported, and shows the file name of the currently-opened LUT.
Have laid the foundations for allowing a high level of flexibility in choosing how nodes of the connectome are plotted. Most of these don't actually work yet, I'm just getting the framework in place for selecting them and updating settings accordingly. I also added the possibility of controlling the transparency of each node, not just its visibility.
As previously, none of these actually do anything yet; just laying the foundations for what is possible...
Producing a single list of those tasks still to be completed in order for the connectome tool to be functional, in preparation for pushing to origin...
Too many to bother listing...
This will allow access to a spherical mesh with level of detail control for other uses.
- Plotting nodes as spheres now includes lighting. - Node visualisation section of the toolbar now uses a grid layout.
This will become a breeding ground for connectome-based operations. Inclusions for now: - Class Mat2Vec, which provides conversion between matrices and vectors (where the vector does not contain symmetric entries). - Simple function verify_matrix() to ensure that a matrix imported from file is square, of the correct size, and symmetrical.
Doesn't plot anything yet, but has a large amount of code in place to set and store visualisation properties.
- Disable all node visualisations. - Only show edges for which both nodes are currently visible. - Prevent user from trying to show edges based on visible nodes, and nodes based on visible edges.
Whenever a vector / matrix file is used to determine visualisation properties of nodes / edges, the corresponding combobox will now display the name of the imported file currently affecting that property.
|
Thanks Jimmy:
|
|
Just to give a few hints with some of the above:
|
Another thing we need to consider, only slightly related to this, is the lighting. At the moment the connectome tool assumes the light position is defined in real space, and therefore does not rotate with the camera. If I change it to become consistent with other tools (i.e. light position is defined in projection space), OrthoView may look weird as the light position would be different in the three views...? |
|
Cool, just thought I'd add my 2 cents... Interesting issue with the lighting in orthoview... Does it actually look that weird if the lighting is anchored to the camera...? |
Don't know, haven't tried it. I think initially I got confused by the lighting implementation in the shaders, and by process of re-doing it the light ended up in a fixed position. I also find that when the light position is fixed in real space and you rotate the camera, you get a better contrast between the diffuse and specular components. But it should be consistent between tools, and that was my main concern with going to an anchored light. |
|
So the issue with a fixed light position is that in some views the light will end up behind the object - it might make for some dramatic screenshots, but not necessarily optimal for viewing... To get around that, we could change the lighting shaders to assume two lights with opposite positions - this probably wouldn't be too much extra work for the shader, I think the only thing that'd need recomputing would be the specular component. And the UI to control the light position would remain as brain-dead simple as it is now. Might be worth a shot? You could add more lights, but at some point it'll start to look like ambient lighting, so you can't push that too far. And you'd need controls for all of them too... |
|
Yeah, that problem is currently highlighted as the viewer initializes to an axial slice but the default light position is superior. I think I'll just revert the lighting in this tool to the standard behaviour; it was mostly me trying to wrap my head around the shader code. Eventually with central lighting settings I'd like to have the option of multiple light sources; shouldn't be too hard UI-wise or shader-wise. I think I'd prefer that to forcing dual lights with opposite positions. Should look OK as long as the diffuse components aren't too high and the specular exponent is large enough. |
|
Multiple lights might be good, but you might find it rapidly gets very messy... You'd have to update all the relevant shaders to match, and there may be an impact on rendering performance (although probably nothing to worry about a great deal). But then, maybe we could move to spherical harmonic lighting - it even involves a bit of spherical convolution! I think that would be most appropriate for MRtrix... |
- Only compute shader variables relevant to lighting if necessary. - Add lighting for edges when displayed as lines or streamlines. - Fix 2D view of edge geometry due to uniform value being sent to wrong shader.
|
OK @chunhungyeh, node list is now a separate dockable widget and the rows are much more narrow to fit more in. Break it if you can! |
|
@Lestropie : I had another fun time playing with the connectome tool today. And nope, I couldn't break it (should I feel sorry about it? 😄 ). Here are some thoughts from my experiment today:
|
Yep: QT provides a small list of selection 'behaviours' for such lists; the one that's most appropriate in this case requires a ctrl-click to deselect, which also means if you've currently got multiple nodes selected, you need to reduce the selection to one node before you can ctrl-click to achieve zero node selection. I think that rather than documenting, I'll add a "De-select all" button.
I think I get where you're trying to go with this. You're suggesting that once a node is selected from the list, the nodes to which it is connected should also be highlighted in some alternative fashion. This idea stems from a presumed foundation of a binary connectome; not only do we promote and encourage the use of weighted connectomes, we don't have a 'central' connectome from which data are drawn (individual data files are loaded for different visual properties). Currently, if a single node is selected, all edges emanating from that node will be highlighted. If a matrix file is used to threshold the visibility of edges, then only a subset of those edges will be visible. It would therefore theoretically be possible to identify those nodes connected via such edges, and apply some other form of highlighting to them. However this would only work if some mechanism is used to limit edge visibility; otherwise all other nodes would be highlighted by such a mechanism (as all possible edges exist until you have data that says otherwise). It would also add an extra row 'block' to the selection highlight settings UI. But at least the logic is sound enough, and expands to the case of multiple nodes being selected... Might have a go at this.
Personally I prefer 'assessing brain network through data-driven analysis'... but that's just me :-P |
When performing manual selection of nodes, the connectome tool now distinguishes between nodes / edges that are 'associated' with the selected nodes (ie. an edge that is connected to one selected node, or a node that has a visible edge connection to a selected node), as opposed to nodes / edges that are in no way involved with the selection. Full settings for controlling how these elements appear visually are also provided.
Use frames to separate the various node selection visibility settings.
- Moved the button for accessing the node selection settings to the top of the frame, and changed it to display an icon instead of text. - Added a 'clear selection' button.
Provides slightly better visuals for the use case where nodes are transparent but edges are not.
|
@Lestropie : I just played with your new commits that have enhanced the node table functionality, and I think that's cool and interesting...pretty sure that it will be a very useful feature. And yes, I do agree with you about the data-driven approach, but I also enjoy those 'visual effects' as they are quite amusing. 😏 |
Just adding some tool tips and removing some comments.
|
👍 |
OK, still got some things to fix up in this, but it's at the point where I'd like people to have a play with it and give some feedback before it's distributed to the masses.
The wiki page will hopefully make things more clear; coming in to it with a clean slate will likely be initially confusing, but it's intentionally designed to be very flexible, and designing it around an easier entry for new users I don't think is possible without losing that flexibility, which will be of particular use when NBS2 is released. I should also add some more tool tips...
https://github.com/MRtrix3/mrtrix3/wiki/Connectome-tool-tutorial