It took me a while to figure out what was meant with
OpenCV Error: Assertion failed (i < 0) in getMat
While searching for this error message I found [a list of error
messages](https://adventuresandwhathaveyou.wordpress.com/2014/03/14/opencv-error-messages-suck/)
which also explained what the problem was: The data type for `rvecs` was
not a simple `cv::Mat` but a `std::vector<cv::Mat>`.
After I fixed that, I got the next error message:
OpenCV Error: Assertion failed (ni > 0 && ni == ni1) in
collectCalibrationData, file
/build/buildd/opencv-2.4.9+dfsg/modules/calib3d/src/calibration.cpp,
line 3193
The problem here was that my data type for the `objectPoints` was just
`vector<Vec3f>` and not `vector<vector<Vec3f>>`.
In order to save other people the time looking for this, I added
explicit examples of the needed data types into the documentation of the
function. I had to re-read the current version a couple of times until I
can read the needed levels of `vector<>`. Having this example would have
really helped me there.
Conflicts:
modules/calib3d/include/opencv2/calib3d.hpp
Also:
- Silence clang warnings about unsupported command line arguments
- Add diagnostic print to calib3d test
- Fixed perf test relative error check
- Fix iOS build problem
Conflicts:
modules/gpu/perf/perf_imgproc.cpp
Cast a long integer to double explicitly.
Conflicts:
modules/python/src2/cv2.cpp
Cast some matrix sizes to type int.
Change some vector mask types to unsigned.
Conflicts:
modules/core/src/arithm.cpp
It took me a while to figure out what was meant with
OpenCV Error: Assertion failed (i < 0) in getMat
While searching for this error message I found [a list of error
messages](https://adventuresandwhathaveyou.wordpress.com/2014/03/14/opencv-error-messages-suck/)
which also explained what the problem was: The data type for `rvecs` was
not a simple `cv::Mat` but a `std::vector<cv::Mat>`.
After I fixed that, I got the next error message:
OpenCV Error: Assertion failed (ni > 0 && ni == ni1) in
collectCalibrationData, file
/build/buildd/opencv-2.4.9+dfsg/modules/calib3d/src/calibration.cpp,
line 3193
The problem here was that my data type for the `objectPoints` was just
`vector<Vec3f>` and not `vector<vector<Vec3f>>`.
In order to save other people the time looking for this, I added
explicit examples of the needed data types into the documentation of the
function. I had to re-read the current version a couple of times until I
can read the needed levels of `vector<>`. Having this example would have
really helped me there.
Spaced methods & functions more consistently, and started documenting
which members does each method access directly or through its callers
within RHO_HEST_REFC.
- Deleted "RefC" from names of external-interface functions.
- Renamed rhorefc.[cpp|hpp] to rho.[cpp|hpp]
- Introduced RHO_HEST base class, from which RHO_HEST_REFC inherits.
- rhoInit() currently only returns a Ptr<RHO_HEST_REFC>, but in the
future it will be allowed to return pointers to other derived classes,
depending on the values returned by cv::checkHardwareSupport().
Cholesky decomposition is stable; It is not necessary to carry it out
internally at double precision if the result will be truncated to single
precision when stored.
- Switched to the extremely fast, while simple and high-quality,
xorshift128+ PRNG algorithm by Sebastiano Vigna in "Further scramblings
of Marsaglia's xorshift generators. CoRR, abs/1402.6246, 2014" (2^128-1
period, passes BigCrush tests). Performance improved by 10% over
random().
- Added an API to allow seeding with a specified seed, rather than using
rand() or random(). This allows deterministic, reproducible results in
tests using our algorithm (although findHomography() does not yet
support passing an entropy source on its own end).
Previously, certain test failures by the method RHO would result in an
error blaming RANSAC instead. The fix involves a parameter change to
several functions in test_homography.cpp.
Implemented a damping-parameter choice strategy similar to that
described in http://www2.imm.dtu.dk/documents/ftp/tr99/tr05_99.pdf.
Removed a few debug statements.
Chosen a new starting lambda value, 0.01.
We now actually output the mask of inliers.
Replaced the complex rules OpenCV uses to select lambda with a naive but
fast heuristic. It's imperfect but produces good results. It is still
subject to the same problem as OpenCV - namely, on occasion LevMarq will
make a poor result even worse.
(performance) Possible inefficient checking for 'lmap' emptiness
(warning) Assignment of function parameter has no effect outside the function. Did you forget dereferencing it?
(style) Array index '<xxx>' is used before limits check
Implements the RHO algorithm as presented in
Paper: Bilaniuk, Olexa, Hamid Bazargani, and Robert Laganiere. "Fast
Target Recognition on Mobile Devices: Revisiting Gaussian Elimination
for the Estimation of Planar Homographies." In Computer Vision and
Pattern Recognition Workshops (CVPRW), 2014 IEEE Conference on, pp.
119-125. IEEE, 2014.
- Complete, heavily documented reference C implementation, as well as
temporarily disabled dirty SSE2 port.
- Enabled tests for RHO in test_homography; Currently these fail
presumably due to too-stringent accuracy requirements.
- Refinement and final refinement are not yet functional; Do not pass
their corresponding flags to RHO.
IPP can be switched on and off on runtime;
Optional implementation collector was added (switched off by default in CMake). Gathers data of implementation used in functions and report this info through performance TS;
TS modifications for implementations control;
