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).