Multiple bugs in cv::LevMarqSparse, which let it crash and not work properly. (Bug #888)


Added by avanindra singh about 14 years ago. Updated over 9 years ago.


Status:Open Start date:
Priority:Normal Due date:
Assignee:- % Done:

0%

Category:legacy, contrib
Target version:-
Affected version:2.4.0 - 2.4.7 Operating System:Linux
Difficulty: HW Platform:x64
Pull request:

Description

ile name: ba.cpp

I have found more than one bug in this implementation. I would list them out:

1) The implementation assumes pointer size to be 32 bit, while on my 64 bit UBUNTU/OPENSUSE system, gcc shows size of pointer to be 64 bit and because of this it crashes during run time.

The matrices A, B, W and Vis_index which store pointers, have type CV_32S. (line 214 - 217). If I chage the type to CV_32SC2, this bug gets fixed.

2) In the method fjac in Jacobian computation, at line 728

CvMat* _mp = cvCreateMat(1, 2, CV_64F ); //projection of the point

The type CV_64F cause assertion failure during run time in cvProjectPoints2 . This bug gets fixed, if I change the type to CV_64FC2 and reduce number of cols to 1, i.e.

CvMat* _mp = cvCreateMat(1, 1, CV_64FC2 ); //projection of the point

The same bug lies in function named 'func', which is used to compute projections. At line 937

CvMat* _mp = cvCreateMat(1, 2, CV_64F ); //projection of the point

again if I change type to CV_64FC2, it gets fixed. Also in this case it would need to be reshaped before
line 963:

cvTranspose( _mp, estim );

i.e.

cvReshape(_mp,_mp,1,0);
cvTranspose( _mp, estim );

3) At line 1106:
params.rowRange(i*num_cam_param + 10,i*num_cam_param+10+numdist).copyTo(distCoeffs[i]);

The distortion being copied is the one which has been given as input for optimization, but rather it should be optimized one. i.e.

(levmar.P).rowRange(i*num_cam_param + 10,i*num_cam_param+10+numdist).copyTo(distCoeffs[i]);

This causes wrong output of optimization.

4) I noticed that the optimization does not let focal length and principal point vary at all, it only changes distortion and motion parameters. Though, I do not have any specific line to point out, but I still believe it is not natural behaviour of bundle adjustment. I compared it's output with sba package provided at http://www.ics.forth.gr/~lourakis/sba/ and sba's output confirms my suspecion.

I wanted to use this implementation in a software. I would be grateful if anyone fixes it soon.

Regards
Avanindra


History

Updated by Alexander Shishkov about 13 years ago

  • Description changed from ile name: ba.cpp I have found more than one bug in this implementation. I wo... to ile name: ba.cpp I have found more than one bug in this implementation. I wo... More

Updated by Alexander Shishkov almost 13 years ago

  • Priority changed from High to Normal
  • Target version deleted ()

Updated by Alexander Shishkov almost 13 years ago

  • Assignee deleted (Vadim Pisarevsky)

Updated by Alexander Shishkov almost 13 years ago

  • Target version deleted ()

Updated by Rui Marques almost 11 years ago

Any special reason why this is open? Not reproducible, no longer relevant (legacy), not enough resources (developer time) to fix?

Updated by Nikita Manovich almost 11 years ago

  • HW Platform set to x64
  • Operating System set to Linux
  • Affected version set to 2.4.0 - 2.4.7

Updated by Maksim Shabunin over 9 years ago

Issue has been transferred to GitHub: https://github.com/Itseez/opencv/issues/4265

Also available in: Atom PDF