Ask Your Question

Result from Euc Distance Calculation

asked 2015-10-20 08:13:48 -0500

zms gravatar image

Hello, I'm calculating the euc line and the degree for 2 points. Most of the results are OK but sometimes there are results showed like this.


May I know what does this means?

The formula for the ecludian distance and the degree (atan) as below.

Point2f a = mc[0]; Point2f b = mc[1]; double res = cv::norm(a-b);

double deg = atan((b.y-a.y)/(b.x-a.x)) * 180 / PI;


edit retag flag offensive close merge delete


Does the a and b points have the same x? If so, there is a division by 0, so just do an if there

thdrksdfthmn gravatar imagethdrksdfthmn ( 2015-10-20 09:51:52 -0500 )edit

based on the output from the program.

 if((mc.size() == 2)&&flagsave==0)
   centroid =2;
   Point2f a = mc[0];
   Point2f b = mc[1];
   double res = cv::norm(a-b);
   std::cout << "Res" <<res << std::endl;
   std::cout << "a" <<a << std::endl;
   std::cout << "b" <<b << std::endl;

  double deg = atan((b.y-a.y)/(b.x-a.x)) * 180 / PI;
  std::cout << "(b.x-a.x)" <<(b.x-a.x) << std::endl;
  std::cout << "(b.y-a.y)" <<(b.y-a.y) << std::endl;
  std::cout << "deg" <<deg<< std::endl;

Results - it does not say it is 0. consistent with -1.#IND. What is that?

 a[-1.#IND, -1.#IND]
 b[65.0653, 30.9768]
zms gravatar imagezms ( 2015-10-20 23:29:32 -0500 )edit

-1.#IND is a kind of infinite, like in division by 0 or something like that

Have you tried to do a res = cv::norm(a, b)? Anyway, the problem is in a, it has already infinite values. How did you compute the mc?

thdrksdfthmn gravatar imagethdrksdfthmn ( 2015-10-21 02:07:25 -0500 )edit

mc is the centroid point by using this vector<point2f> mc( contours.size() );

for( int i = 0; i < contours.size(); i++ ) { mc[i] = Point2f( mu[i].m10/mu[i].m00 , mu[i].m01/mu[i].m00 ); circle( draw, mc[i], 4, Scalar(0,0,255), -1, 8, 0 );//waitKey(0); }

I get the blob area binary image and calculate the centroid of the white blob area.

zms gravatar imagezms ( 2015-10-21 02:48:28 -0500 )edit

So, you are doing a division by mu[i].m00 There may be the cause of the -1.#IND. Check for the cause there ;)

thdrksdfthmn gravatar imagethdrksdfthmn ( 2015-10-21 03:32:13 -0500 )edit

@thdrksdfthmn u are correct. I details out the value and found out this.

m10/mu[i].m0 = 00

Is it anyway that I can solve on this matter?

zms gravatar imagezms ( 2015-10-22 01:58:54 -0500 )edit

Your moments are computed on a binary image, so you need to look in that image, what are the problems, why is it 0? Does the image have any white regions? If you find why is that 0, then you shall treat that case special. Bu what version of OpenCV are you using? Could this be a bug, from theory: m00, could be 0 only if all the points have at least one coordinate 0?

thdrksdfthmn gravatar imagethdrksdfthmn ( 2015-10-22 02:27:53 -0500 )edit

I found out that, the output seeing a very small white region at (0,0) which is proven inside the image where I draw a line from another centroid which is quite weird. I'm using 2.4.11 opencv version. Is it a bug or something else?

zms gravatar imagezms ( 2015-10-22 04:39:32 -0500 )edit

I do not think it is a bug (but it may be treated by someone as a special case). I would say that you r problem is in the image, why do you have that white top-left corner region (one pixel, or something like that)? I would suggest you to find why do you get in this case and fix the problem there

thdrksdfthmn gravatar imagethdrksdfthmn ( 2015-10-22 06:33:37 -0500 )edit

Hope it helped ;)

thdrksdfthmn gravatar imagethdrksdfthmn ( 2015-10-22 07:24:28 -0500 )edit

1 answer

Sort by ยป oldest newest most voted

answered 2015-10-22 07:11:24 -0500

zms gravatar image

ok noted.. thanks for all the explaination. :)

edit flag offensive delete link more

Question Tools

1 follower


Asked: 2015-10-20 08:13:48 -0500

Seen: 222 times

Last updated: Oct 20 '15