Revision history - OpenCV Q&A Forum

Many thanks Eduardo for your thorough analysis, and the time you invested for it :-)

This is not an answer, but a recap of my results following your suggestions. I was much less sucessful than you : I saw unstable results when using the optimized version, and no success when disabling the optimizations.

Here is a recap of what I saw:

using opencv 2.4.11: cv::setUseOptimized(false) does not change the result
using opencv 3.1 : cv::setUseOptimized(false) leads to unstable results!

Here is a full recap of my results with opencv 3.1:

Using cv::SOLVEPNP_UPNP
- optimized version : if you run the program several times, the result you get can be 4535.94, 711.716, 302630, nan or 0 !!!
- unoptimized version : result is always 711.832
Using cv::SOLVEPNP_DLS
- optimized version: result vary. I obtained 0 or 28009.6 or 711.832
- unoptimized version : the result is consistently 711.832 pixels
Using cv::SOLVEPNP_EPNP
- optimized version : 0 or 711.881 or 4535.94 or nan
- unoptimized version : 711.832
Using cv::SOLVEPNP_P3P
- optimized version : 5248.22, 712.084, 30.1587 or 0 * unoptimized version : 711.832
Using CV_ITERATIVE
- optimized version : 8.94
- unoptimized version : 8.94

Notes:

I did not understand your remark "if we don't cast to float values, cv::SOLVEPNP_ITERATIVE return completly wrong results". Where did you add a cast?
On which OS did you make your tests ?
We do have a bug, don't you think ?

Many thanks Eduardo for your thorough analysis, and the time you invested for it :-)

This is not an answer, but a recap of my results following your suggestions. I was much less sucessful than you : I saw unstable results when using the optimized version, and no success when disabling the optimizations.

Note : my tests were run under OSX El Capitan. I did not test linux or windows yet.

Here is a recap of what I saw:

using opencv 2.4.11: cv::setUseOptimized(false) does not change the result
using opencv 3.1 : cv::setUseOptimized(false) leads to unstable results!

Here is a full recap of my results with opencv 3.1:

Using cv::SOLVEPNP_UPNP
- optimized version : if you run the program several times, the result you get can be 4535.94, 711.716, 302630, nan or 0 !!!
- unoptimized version : result is always 711.832
Using cv::SOLVEPNP_DLS
- optimized version: result vary. I obtained 0 or 28009.6 or 711.832
- unoptimized version : the result is consistently 711.832 pixels
Using cv::SOLVEPNP_EPNP
- optimized version : 0 or 711.881 or 4535.94 or nan
- unoptimized version : 711.832
Using cv::SOLVEPNP_P3P
- optimized version : 5248.22, 712.084, 30.1587 or 0 * unoptimized version : 711.832
Using CV_ITERATIVE
- optimized version : 8.94
- unoptimized version : 8.94

Notes:

I did not understand your remark "if we don't cast to float values, cv::SOLVEPNP_ITERATIVE return completly wrong results". Where did you add a cast?
On which OS did you make your tests ?
We do have a bug, don't you think ?

Many thanks Eduardo for your thorough analysis, and the time you invested for it :-)

This is not an answer, but a recap of my results following your suggestions. I was much less sucessful than you : I saw unstable results when using the optimized version, and no success when disabling the optimizations.

Note : my tests were run under OSX El Capitan. I did not test linux or windows yet.

Here is a recap of what I saw:

using opencv 2.4.11: cv::setUseOptimized(false) does not change the result
using opencv 3.1 : cv::setUseOptimized(false) leads to unstable results!

Here is a full recap of my results with opencv ~~3.1:~~3.1. I also tested the master branch, with the same results:

Using cv::SOLVEPNP_UPNP
- optimized version : if you run the program several times, the result you get can be 4535.94, 711.716, 302630, nan or 0 !!!
- unoptimized version : result is always 711.832
Using cv::SOLVEPNP_DLS
- optimized version: result vary. I obtained 0 or 28009.6 or 711.832
- unoptimized version : the result is consistently 711.832 pixels
Using cv::SOLVEPNP_EPNP
- optimized version : 0 or 711.881 or 4535.94 or nan
- unoptimized version : 711.832
Using cv::SOLVEPNP_P3P
- optimized version : 5248.22, 712.084, 30.1587 or 0 * unoptimized version : 711.832
Using CV_ITERATIVE
- optimized version : 8.94
- unoptimized version : 8.94

Notes:

I did not understand your remark "if we don't cast to float values, cv::SOLVEPNP_ITERATIVE return completly wrong results". Where did you add a cast?
On which OS did you make your tests ?
We do have a bug, don't you think ?

Note : this answer was edited following Eduardo's edit of his own answer. The initial unstable results under OSX were due to an error in the code. Sorry about this.

Many thanks Eduardo for your thorough analysis, and the time you invested for it :-)

This is not an answer, but a recap of my results following your ~~suggestions. I was much less sucessful than you : I saw unstable results when using the optimized version, and no success when disabling the optimizations.~~ suggestions.

Note : my tests were run under OSX El Capitan. I did not test linux or windows ~~yet.~~

yet. I have the same results as you :

With cv::SOLVEPNP_DLS, cv::SOLVEPNP_EPNP, cv::SOLVEPNP_UPNP , the reprojection error is 44.8698 pixels
With cv::SOLVEPNP_ITERATIVE the reprojection error is 8.94 pixels (except if you set useExtrinsicGuess to true and use null vectors as inital rotation and translation}

~~I was much less sucessful than you : I saw unstable results when using the optimized version, and no success when disabling the optimizations.~~

Here is a recap of what I saw:

using opencv 2.4.11: cv::setUseOptimized(false) does not change the result

using opencv 3.1 : cv::setUseOptimized(false) leads to unstable results!

Here is a full recap of my results with opencv 3.1. I also tested the master branch, with the same results:

Using cv::SOLVEPNP_UPNP

optimized version : if you run the program several times, the result you get can be 4535.94, 711.716, 302630, nan or 0 !!!

unoptimized version : result is always 711.832

Using cv::SOLVEPNP_DLS

optimized version: result vary. I obtained 0 or 28009.6 or 711.832

unoptimized version : the result is consistently 711.832 pixels

Using cv::SOLVEPNP_EPNP

optimized version : 0 or 711.881 or 4535.94 or nan

unoptimized version : 711.832

Using cv::SOLVEPNP_P3P

optimized version : 5248.22, 712.084, 30.1587 or 0 * unoptimized version : 711.832

~~Using CV_ITERATIVE~~
Notes:
- I did not understand your remark "if we don't cast to float values, cv::SOLVEPNP_ITERATIVE return completly wrong results". Where did you add a cast?
- On which OS did you make your tests ?
- We do have a bug, don't you think ?

Note : this answer was edited following Eduardo's edit of his own answer. The initial unstable results under OSX were due to an error in the code. Sorry about this.

Many thanks Eduardo for your thorough analysis, and the time you invested for it :-)

This is not an answer, but a recap of my results following your suggestions.

Note : my tests were run under OSX El Capitan. I did not test linux or windows yet. I have the same results as you :

With cv::SOLVEPNP_DLS, cv::SOLVEPNP_EPNP, cv::SOLVEPNP_UPNP , the reprojection error is 44.8698 pixels
With cv::SOLVEPNP_ITERATIVE the reprojection error is 8.94 pixels (except if you set useExtrinsicGuess to true and use null vectors as inital rotation and translation}

With cv::SOLVEPNP_P3P the reprojection error is about 0.21 pixels

~~I was much less sucessful than you : I saw unstable results when using the optimized version, and no success when disabling the optimizations.~~

Here is a recap of what I saw:

using opencv 2.4.11: cv::setUseOptimized(false) does not change the result

using opencv 3.1 : cv::setUseOptimized(false) leads to unstable results!

Here is a full recap of my results with opencv 3.1. I also tested the master branch, with the same results:

Using cv::SOLVEPNP_UPNP

optimized version : if you run the program several times, the result you get can be 4535.94, 711.716, 302630, nan or 0 !!!

unoptimized version : result is always 711.832

Using cv::SOLVEPNP_DLS

optimized version: result vary. I obtained 0 or 28009.6 or 711.832

unoptimized version : the result is consistently 711.832 pixels

Using cv::SOLVEPNP_EPNP

optimized version : 0 or 711.881 or 4535.94 or nan

unoptimized version : 711.832

Using cv::SOLVEPNP_P3P

optimized version : 5248.22, 712.084, 30.1587 or 0 * unoptimized version : 711.832

~~Using CV_ITERATIVE~~
- ~~unoptimized version : 8.94~~

Notes:

I did not understand your remark "if we don't cast to float values, cv::SOLVEPNP_ITERATIVE return completly wrong results". Where did you add a cast?
On which OS did you make your tests ?
We do have a bug, don't you think ?

Note : this answer was edited following Eduardo's edit of his own answer. The initial unstable results under OSX were due to an error in the code. Sorry about this.

Many thanks Eduardo for your thorough analysis, and the time you invested for it :-)

This is not an answer, but a recap of my results following your suggestions.

Note : my tests were run under OSX El Capitan. I did not test linux or windows yet. I have the same results as you :

With cv::SOLVEPNP_DLS, cv::SOLVEPNP_EPNP, cv::SOLVEPNP_UPNP , the reprojection error is 44.8698 pixels
With cv::SOLVEPNP_ITERATIVE the reprojection error is 8.94 pixels (except if you set useExtrinsicGuess to true and use null vectors as inital rotation and ~~translation}~~translation}, and the returned pose is behind the camera
With cv::SOLVEPNP_P3P the reprojection error is about 0.21 pixels

~~I was much less sucessful than you : I saw unstable results when using the optimized version, and no success when disabling the optimizations.~~

Here is a recap of what I saw:

using opencv 2.4.11: cv::setUseOptimized(false) does not change the result

using opencv 3.1 : cv::setUseOptimized(false) leads to unstable results!

Here is a full recap of my results with opencv 3.1. I also tested the master branch, with the same results:

Using cv::SOLVEPNP_UPNP

optimized version : if you run the program several times, the result you get can be 4535.94, 711.716, 302630, nan or 0 !!!

unoptimized version : result is always 711.832

Using cv::SOLVEPNP_DLS

optimized version: result vary. I obtained 0 or 28009.6 or 711.832

unoptimized version : the result is consistently 711.832 pixels

Using cv::SOLVEPNP_EPNP

optimized version : 0 or 711.881 or 4535.94 or nan

unoptimized version : 711.832

Using cv::SOLVEPNP_P3P

optimized version : 5248.22, 712.084, 30.1587 or 0 * unoptimized version : 711.832

~~Using CV_ITERATIVE~~
- ~~unoptimized version : 8.94~~

Notes:

I did not understand your remark "if we don't cast to float values, cv::SOLVEPNP_ITERATIVE return completly wrong results". Where did you add a cast?
On which OS did you make your tests ?
We do have a bug, don't you think ?

Note 1 : this answer was edited following Eduardo's edit of his own answer. The initial unstable results under OSX were due to an error in the code. Sorry about this.

Note 2 : I made a more thorough analysis, that compares several strategies (after having added the distorsion coeffs of the camera). The code can would not fit here, but it can be found at https://github.com/pthom/TestSolvePnp

enum SolvePnpStrategy
{
  Strategy_MySolvePnp_Epnp, //an home baked adapter of epnp using the epnp library source code
  Strategy_MySolvePnpPosit, //an home baked adapter of cvPOSIT (deprecated "OpenCV 1" pose estimation method)
  Strategy_solvePnp_P3p,    // opencv SOLVEPNP_P3P method
  Strategy_solvePnp_Iterative_InitialGuess, // opencv SOLVEPNP_ITERATIVE method with an initial guess
  Strategy_solvePnp_Epnp //opencv SOLVEPNP_EPNP method
};

Based on my experimentations, the order of the 3d points and image points does matter. It has to be adapted depending upon the strategy !

With opencv's SOLVEPNP_EPNP the error can go down to 23.03 pixel. The order of the points does matter
With MySolvePnpEpnp (an home baked adapter of epnp using the epnp library source code), the error is about 6.742 pixels, and the order is important It is strange that this "rewrite" gives different results
With MySolvePnpPosit, the error is about 4.911 pixels and the order is important (in other cases the reprojection error is about 1278 pixels !)
With solvePnp_P3p (cv::SOLVEPNP_P3P) the error is about 0.02961 pixels and the order does not matter much
With solvePnp_P3p (cv::SOLVEPNP_ITERATIVE) the error can be 0 pixels if a good initial extrinsic guess is given (otherwise don't hope for any convergence). The order does not matter much with SOLVEPNP_ITERATIVE.

Original answer below

Many thanks Eduardo for your thorough analysis, and the time you invested for it :-)

This is not an answer, but a recap of my results following your suggestions.

Note : my tests were run under OSX El Capitan. I did not test linux or windows yet. I have the same results as you :

With cv::SOLVEPNP_DLS, cv::SOLVEPNP_EPNP, cv::SOLVEPNP_UPNP , the reprojection error is 44.8698 pixels
With cv::SOLVEPNP_ITERATIVE the reprojection error is 8.94 pixels (except if you set useExtrinsicGuess to true and use null vectors as inital rotation and translation}, and the returned pose is behind the camera
With cv::SOLVEPNP_P3P the reprojection error is about 0.21 pixels

~~I was much less sucessful than you : I saw unstable results when using the optimized version, and no success when disabling the optimizations.~~

Here is a recap of what I saw:

using opencv 2.4.11: cv::setUseOptimized(false) does not change the result

using opencv 3.1 : cv::setUseOptimized(false) leads to unstable results!

Here is a full recap of my results with opencv 3.1. I also tested the master branch, with the same results:

Using cv::SOLVEPNP_UPNP

optimized version : if you run the program several times, the result you get can be 4535.94, 711.716, 302630, nan or 0 !!!

unoptimized version : result is always 711.832

Using cv::SOLVEPNP_DLS

optimized version: result vary. I obtained 0 or 28009.6 or 711.832

unoptimized version : the result is consistently 711.832 pixels

Using cv::SOLVEPNP_EPNP

optimized version : 0 or 711.881 or 4535.94 or nan

unoptimized version : 711.832

Using cv::SOLVEPNP_P3P

optimized version : 5248.22, 712.084, 30.1587 or 0 * unoptimized version : 711.832

~~Using CV_ITERATIVE~~
- ~~unoptimized version : 8.94~~

Notes:

I did not understand your remark "if we don't cast to float values, cv::SOLVEPNP_ITERATIVE return completly wrong results". Where did you add a cast?
On which OS did you make your tests ?
We do have a bug, don't you think ?

Note 1 : this answer was edited following Eduardo's edit of his own answer. The initial unstable results under OSX were due to an error in the code. Sorry about this.

Note 2 : I made a more thorough analysis, that compares several strategies (after having added the distorsion coeffs of the camera). The code ~~can~~ would not fit here, but it can be found at https://github.com/pthom/TestSolvePnp

enum SolvePnpStrategy
{
  Strategy_MySolvePnp_Epnp, //an home baked adapter of epnp using the epnp library source code
  Strategy_MySolvePnpPosit, //an home baked adapter of cvPOSIT (deprecated "OpenCV 1" pose estimation method)
  Strategy_solvePnp_P3p,    // opencv SOLVEPNP_P3P method
  Strategy_solvePnp_Iterative_InitialGuess, // opencv SOLVEPNP_ITERATIVE method with an initial guess
  Strategy_solvePnp_Epnp //opencv SOLVEPNP_EPNP method
};

Based on my experimentations, the order of the 3d points and image points does matter. It has to be adapted depending upon the strategy !

With opencv's SOLVEPNP_EPNP the error can go down to 23.03 pixel. The order of the points does matter
With MySolvePnpEpnp (an home baked adapter of epnp using the epnp library source code), the error is about 6.742 pixels, and the order is important It is strange that this "rewrite" gives different results
With MySolvePnpPosit, the error is about 4.911 pixels and the order is important (in other cases the reprojection error is about 1278 pixels !)
With solvePnp_P3p (cv::SOLVEPNP_P3P) the error is about 0.02961 pixels and the order does not matter much
With solvePnp_P3p (cv::SOLVEPNP_ITERATIVE) the error can be 0 pixels if a good initial extrinsic guess is given (otherwise don't hope for any convergence). The order does not matter much with SOLVEPNP_ITERATIVE.

Original answer below

Many thanks Eduardo for your thorough analysis, and the time you invested for it :-)

This is not an answer, but a recap of my results following your suggestions.

Note : my tests were run under OSX El Capitan. I did not test linux or windows yet. I have the same results as you :

With cv::SOLVEPNP_DLS, cv::SOLVEPNP_EPNP, cv::SOLVEPNP_UPNP , the reprojection error is 44.8698 pixels
With cv::SOLVEPNP_ITERATIVE the reprojection error is 8.94 pixels (except if you set useExtrinsicGuess to true and use null vectors as inital rotation and translation}, and the returned pose is behind the camera
With cv::SOLVEPNP_P3P the reprojection error is about 0.21 pixels

~~I was much less sucessful than you : I saw unstable results when using the optimized version, and no success when disabling the optimizations.~~

Here is a recap of what I saw:

using opencv 2.4.11: cv::setUseOptimized(false) does not change the result

using opencv 3.1 : cv::setUseOptimized(false) leads to unstable results!

Here is a full recap of my results with opencv 3.1. I also tested the master branch, with the same results:

Using cv::SOLVEPNP_UPNP

optimized version : if you run the program several times, the result you get can be 4535.94, 711.716, 302630, nan or 0 !!!

unoptimized version : result is always 711.832

Using cv::SOLVEPNP_DLS

optimized version: result vary. I obtained 0 or 28009.6 or 711.832

unoptimized version : the result is consistently 711.832 pixels

Using cv::SOLVEPNP_EPNP

optimized version : 0 or 711.881 or 4535.94 or nan

unoptimized version : 711.832

Using cv::SOLVEPNP_P3P

optimized version : 5248.22, 712.084, 30.1587 or 0 * unoptimized version : 711.832

~~Using CV_ITERATIVE~~
- ~~unoptimized version : 8.94~~

Notes:

I did not understand your remark "if we don't cast to float values, cv::SOLVEPNP_ITERATIVE return completly wrong results". Where did you add a cast?
On which OS did you make your tests ?
We do have a bug, don't you think ?

Note 1 : this answer was edited following Eduardo's edit of his own answer. The initial unstable results under OSX were due to an error in the code. Sorry about this.

Note 2 : I made a more thorough analysis, that compares several strategies (after having added the distorsion coeffs of the camera). The code would not fit here, but it can be found at https://github.com/pthom/TestSolvePnp

enum SolvePnpStrategy
{
  Strategy_MySolvePnp_Epnp, //an home baked adapter of epnp using the epnp library source code
  Strategy_MySolvePnpPosit, //an home baked adapter of cvPOSIT (deprecated "OpenCV 1" pose estimation method)
  Strategy_solvePnp_P3p,    // opencv SOLVEPNP_P3P method
  Strategy_solvePnp_Iterative_InitialGuess, // opencv SOLVEPNP_ITERATIVE method with an initial guess
  Strategy_solvePnp_Epnp //opencv SOLVEPNP_EPNP method
};

Based on my experimentations, the order of the 3d points and image points does matter. It has to be adapted depending upon the strategy !

With opencv's SOLVEPNP_EPNP the error can go down to 23.03 pixel. The order of the points does matter
With MySolvePnpEpnp (an home baked adapter of epnp using the epnp library source code), the error is about 6.742 pixels, and the order is important It is strange that this "rewrite" gives different results
With MySolvePnpPosit, the error is about 4.911 pixels and the order is important (in other cases the reprojection error is about 1278 pixels !)
With solvePnp_P3p (cv::SOLVEPNP_P3P) the error is about 0.02961 pixels and the order does not matter much
With ~~solvePnp_P3p~~ solvePnp_Iterative_InitialGuess (cv::SOLVEPNP_ITERATIVE) the error can be 0 pixels if a good initial extrinsic guess is given (otherwise don't hope for any convergence). The order does not matter much with SOLVEPNP_ITERATIVE.

Original answer below

Many thanks Eduardo for your thorough analysis, and the time you invested for it :-)

This is not an answer, but a recap of my results following your suggestions.

Note : my tests were run under OSX El Capitan. I did not test linux or windows yet. I have the same results as you :

With cv::SOLVEPNP_DLS, cv::SOLVEPNP_EPNP, cv::SOLVEPNP_UPNP , the reprojection error is 44.8698 pixels
With cv::SOLVEPNP_ITERATIVE the reprojection error is 8.94 pixels (except if you set useExtrinsicGuess to true and use null vectors as inital rotation and translation}, and the returned pose is behind the camera
With cv::SOLVEPNP_P3P the reprojection error is about 0.21 pixels

~~I was much less sucessful than you : I saw unstable results when using the optimized version, and no success when disabling the optimizations.~~

Here is a recap of what I saw:

using opencv 2.4.11: cv::setUseOptimized(false) does not change the result

using opencv 3.1 : cv::setUseOptimized(false) leads to unstable results!

Here is a full recap of my results with opencv 3.1. I also tested the master branch, with the same results:

Using cv::SOLVEPNP_UPNP

optimized version : if you run the program several times, the result you get can be 4535.94, 711.716, 302630, nan or 0 !!!

unoptimized version : result is always 711.832

Using cv::SOLVEPNP_DLS

optimized version: result vary. I obtained 0 or 28009.6 or 711.832

unoptimized version : the result is consistently 711.832 pixels

Using cv::SOLVEPNP_EPNP

optimized version : 0 or 711.881 or 4535.94 or nan

unoptimized version : 711.832

Using cv::SOLVEPNP_P3P

optimized version : 5248.22, 712.084, 30.1587 or 0 * unoptimized version : 711.832

~~Using CV_ITERATIVE~~
- ~~unoptimized version : 8.94~~

Notes:

I did not understand your remark "if we don't cast to float values, cv::SOLVEPNP_ITERATIVE return completly wrong results". Where did you add a cast?
On which OS did you make your tests ?
We do have a bug, don't you think ?

Revision history [back]