@bogovicj: okay, so you are pointing on the difference between graph theory vs. (something like an) “edge growing process” in the implementation?
I have to admit that I’m just starting to have a look on maxflow/mincut implementations and can’t really discuss about this. Assume that there is something like an edge growing process I think the number of new edges the code is taking into account for sure depends on the spatial directions of progress (one implemented) and the neighburhood (which one defined by the implementation). In this context I was just wondering how you came to this statement? [quote=“bogovicj, post:4, topic:5728”]
In 3D, a voxel can have 8, 16, or 32 neighbors.
What basics I know about terms of a regular graph with nodes(=pixel) and edges(=connections between pixels/nodes) so far (see Wiki):
- in 2D you can have horizontal+vertical edges (4-connectivity), or inclusive diagonal edges (8-connectivity). - btw in Graph_Cut.java there is a private boolean eightconnect which is set as true.
- in 3D you can have 6-connectivity or 26-connectivity (in the same fashion as 2D)
So in this context I was just wondering how it makes sense, that one gets this confusing output in the log.
But as you pointed out, this output might be just the additional number of connection/edges which are added to those which were already gathered.
So what do you think about what I concluded for myself? …
- in general the plugin builds an undirected graph, which means the edges are bidirectional
- given a 2D image: the plugin assumes an 8-connectivity between the nodes/pixels
- given a stack: the plugin assumes an ???-connectivity
Is it possible that some functionalities are implemented as possible to work in 3D but some functionalitiies (e.g. eightconnect) are just supposed to be used for 2D images exclusively?
What do you reckon? Sorry, when I didn’t get your point correctly. Any suggestions?
For now, I will simply test the difference between 2D vs 3D results, but some insights would be cool.
Thanks a lot for the disucssion