You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When applying your codebase to my works, I discovered a problem within glomap/math/tree.cc. I think there's something wrong with this MaximumSpanningTree (mst) function.
Specifically, I gave this function a rather small input - simply 10 images - and printed all the information about the graph:
I summed these weights up and can tell this is a legal spanning tree with correct total weight. However, I used other code to calculate the mst of the same problem, and after my verification, this is not the mst for the problem, as the following one is better:
After my exploration I suppose that the problem originates from boost library, as its implementation may not support negative edge weights, so I changed the calculation of weights from weights_boost[e] = -image_pair.inliers.size(); to weights_boost[e] = 1e6-image_pair.inliers.size(); to avoid negative weights, then your code can calculate correct results too. Of course this is an easy fix, and I don't know the actual effect of this mathematical bug, just think it should work as it is supposed to do.
The text was updated successfully, but these errors were encountered:
I've made a pull request here: #90 (comment). In my implementation I find out the biggest weight and add that value to all the weights, so that all weights should be >= 0.
When applying your codebase to my works, I discovered a problem within
glomap/math/tree.cc
. I think there's something wrong with this MaximumSpanningTree (mst) function.Specifically, I gave this function a rather small input - simply 10 images - and printed all the information about the graph:
These are the edges with their nodes and weight. And the result I get:
I summed these weights up and can tell this is a legal spanning tree with correct total weight. However, I used other code to calculate the mst of the same problem, and after my verification, this is not the mst for the problem, as the following one is better:
After my exploration I suppose that the problem originates from boost library, as its implementation may not support negative edge weights, so I changed the calculation of weights from
weights_boost[e] = -image_pair.inliers.size();
toweights_boost[e] = 1e6-image_pair.inliers.size();
to avoid negative weights, then your code can calculate correct results too. Of course this is an easy fix, and I don't know the actual effect of this mathematical bug, just think it should work as it is supposed to do.The text was updated successfully, but these errors were encountered: