The assert failure in add_edge() of graph.h

[wangmaoCS]

I modify the code on the Linux OS with OpenCV 2.4.13.6 and catch the assert failure ( assert(-i != _j) in add_edge of graph.h ) error when running with 'use_graph_cut=true' .

This problem may come from the construction of 'neighbours' in Run() function of 'GCRANSAC.h'.
In my understanding, the 'neighbours' data structure contains the neighborhood relationship between nodes. For node i, its neighbor node list is neghours[i] and the first node (neghours[i][0]) should be i.

However, it seems that in my experiment, the first node is not i return by the FLANN. Then in the Labeling() function, the following code will result in the same i and n_idx, which will cause the assert error when running the function add_term2()

for (int i = 0; i < points.rows; ++i)
{
			float distance1 = static_cast<float>(estimator.Error(points.row(i), model));
			float energy1 = exp(-(distance1*distance1) / sqr_thr);

			for (int j = 1; j < neighbors[i].size(); ++j)
			{
				int n_idx = neighbors[i][j].trainIdx;

				float distance2 = static_cast<float>(estimator.Error(points.row(n_idx), model));
				float energy2 = exp(-(distance2*distance2) / sqr_thr);
				
				const float e00 = 0.5f * (energy1 + energy2);
				const float e01 = 1;
				const float e10 = 1;
				const float e11 = 1 - 0.5f * (energy1 + energy2);

				if (e00 + e11 > e01 + e10)
					printf("Non-submodular expansion term detected; smooth costs must be a metric for expansion\n");

				e->add_term2(i, n_idx, e00*lambda, e01*lambda, e10*lambda, e11*lambda);
			}

I'm not sure if I get the right meaning of 'neighbours' .
However, when I fix this bug, I get the right result.

Another issue is about the running time.
I have deleted all concurrency namespace due to the Linux environment.
The running time with GCRANSAC is larger than the version without it , i.e. set the use_graph_cut=false.
However, there can be more right matches with GCRANSAC.

[Daniel Barath]

I have never experienced this, but fixed! (Hopefully...)

[wangmaoCS]

You are so fast! :-)
I think the problem may come from the different implementation of flann in OpenCV on different platform.

[wangmaoCS]

Your updated code will get the right result in my experiment.

[Daniel Barath]

Yeah, this is probably the reason :)
Ok, so both of us are happy!