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
Update android+AsyncServiceHelper.java
Update android+AsyncServiceHelper.java
changed tabs in last commit to spaces
Update android+AsyncServiceHelper.java
small formatting fixes
removed separate example for reading image sequences and modified starter_video.cpp to better explain the functionality of VideoCapture. I also added a bit more explanation in the documentation of the VideoCapture interface
Conflicts:
modules/highgui/doc/reading_and_writing_images_and_video.rst
samples/cpp/starter_video.cpp
starter_video.cpp changed CV WINDOW KEEPRATIO to just WINDOW KEEPTATIO to fix build error
starter_video.cpp hid local functions
(use "git reset HEAD <file>..." to unstage)
modified: highgui/include/opencv2/highgui/highgui_c.h
modified: highgui/src/cap_dshow.cpp
modified: java/generator/gen_java.py
The correction of the orthographic error in the enumeration constant
CAP_PROP_MONOCROME has been undone.
Explicitly linking to a Python framework on OS X prevents modules from
being built against one python (i.e. system python) and imported from
another (i.e. Homebrew python); the interpreter segfaults if there's a
linkage to a foreign python. Building the module with `-undefined
dynamic_lookup` instead of an explicit link allows the symbols to be
resolved at load time from a compatible python.
(use "git reset HEAD <file>..." to unstage)
modified: modules/highgui/include/opencv2/highgui/highgui_c.h
modified: modules/highgui/src/cap_dshow.cpp
modified: modules/highgui/src/cap_pvapi.cpp
modified: modules/java/generator/gen_java.py
Änderungen in der PvAPI hinzugefügt.
Current implementation of miniflann is releasing the trained index, and
rebuilding the index from the beginning.
But, some indexing algorithms like the LSH are able to add the indexing
data after that.
This branch is implementation of that optimization for LshIndex
FlannBasedMatcher in the feature2d.
previous implementation was not thread/stream safe, since it used constant
memory
new implementation doesn't use any global objects, so it is thread/stream safe
move hog::set_up_constants from constructor to compute method
if user changed CUDA device between constructor and computation,
some variables were uninitialized
1) Fixed deadlock if camera is started and stopped immediately
2) Invalid pattern usage of Object.wait(). Refer to "spurious wakeup": http://docs.oracle.com/javase/8/docs/api/java/lang/Object.html#wait
3) Fixed buffer usage:
a) fix eliminates processing of zero NV12 (green in RGB) first frame
b) latest ready frame is delivered for processing (not previous)
For Bug #3714, user use the imshow() function without calling
namedWindow() properly, because user did not know the implicit rule for
imshow(). (i.e. without calling namedWindow implied calling namedWindow(
,CV__WINDOW_AUTOSIZE).
Improve the Display Image Tutorial to educate the user for such implied
rule.
Put a note on documentation for Bug#3714
Revise the documentation regarding to imshow() function to better
educate the user the implicit rule. (i.e. without creating the window
before the imshow() function is the same as creating AUTOSIZE window)
Move some static functions into the FarnebackOpticalFlow class as well,
so they can access these new class variables.
oclMat objects cannot be declared statically, because their destructor
depends on the statically defined __module variable from cl_context.cpp.
Since statically defined variables in separate compilation units have
an undefined destruction order there is always the possibility the
__module will be destructed before an oclMat object, which results
in a segfault.
gauss_w_lut is a statically defined variable of type oclMat. The oclMat
destructor calls openCLFree() which via getInitializationMutex() accesses
the __module variable which has been statically defined in cl_context.cpp
Since the destruction order of statically defined variables in different
compilation units is undefined, it is possible that __module will
be destructed before gauss_w_lut, which would result in a segfault when
getInitializationMutex() is called while destructing gauss_w_lut.
In order to avoid this issue, we need to make gauss_w_lut a private
member of the HOGDescriptors class so we know it will be destroyed
before __module.
This is actually the same warning that the suppression at the bottom
suppresses, but that one doesn't suppress it when using a native compiler
(go figure).
I remove the forced inclusion of precompiled headers into all sources,
since otherwise this workaround doesn't work - the header with the warning
is included before I can use a pragma.
series are supported. Testing this with both cams for Windows and Linux
exhaustively.
Optimizing memory footprint by removing unused calls.
Adapted with the input of Shai
Added small example that illustrates how it should work.
superres module fails to compile with the following error messages:
[100%] Building CXX object modules/superres/CMakeFiles/opencv_superres.dir/src/super_resolution.cpp.o
/opencv-2.4.10/modules/superres/src/frame_source.cpp: In function 'cv::Ptr<cv::superres::FrameSource> cv::superres::createFrameSource_Video_GPU(const string&)':
/opencv-2.4.10/modules/superres/src/frame_source.cpp:263:16: error: expected type-specifier before 'VideoFrameSource'
/opencv-2.4.10/modules/superres/src/frame_source.cpp:263:16: error: could not convert '(int*)operator new(4ul)' from 'int*' to 'cv::Ptr<cv::superres::FrameSource>'
/opencv-2.4.10/modules/superres/src/frame_source.cpp:263:16: error: expected ';' before 'VideoFrameSource'
/opencv-2.4.10/modules/superres/src/frame_source.cpp:263:41: error: 'VideoFrameSource' was not declared in this scope
/opencv-2.4.10/modules/superres/src/frame_source.cpp:264:1: error: control reaches end of non-void function [-Werror=return-type]
cc1plus: some warnings being treated as errors
make[3]: *** [modules/superres/CMakeFiles/opencv_superres.dir/src/frame_source.cpp.o] Error 1
make[3]: *** Waiting for unfinished jobs....
This is caused because the return value of the createFrameSource_Video_GPU function should be a VideoFrameSource_GPU object.
ocl: Change static variable order in cl_context.cpp to avoid crashes during destruction
ContextImpl::currentContext contains a reference to one of the
DeviceInfoImpl objects from:
static std::vector<DeviceInfoImpl> global_devices;
ContextImpl::currentContext is destroyed in the destructor
for the statically defined object __module, and relies on its
DeviceInfoImpl reference to query some hardware features while
being destroyed.
This means that we need to ensure that the global_devices vector is
destroyed affter __module, otherwise ContextImpl::currentContext's
DeviceInfoImpl reference will no longer be valid when __module is
destroyed.
Since these variables are all confined to a single compilation unit,
they will be destruct from bottom to top, so we need to make sure
that __module is the bottom definition so it can be destroyed first.
iOS: fix crash from overrelease in UIImageToMat
viz: fixed memory leak, issue 3961
fix installation layout for debian packages:
Install symlinks to shared libraries as a part of development package,
not runtime package.
It is default behavior for debian packages.
Fix test name.
TIFF loader: Allocate large enough buffer when (bpp * ncn) > 8.
TIFF loader: Pass buffer size to read functions.
replace not ascii and not cyrillic symbols with '?';
add test for putText;
fix warning;
minor fixes;
ContextImpl::currentContext contains a reference to one of the
DeviceInfoImpl objects from:
static std::vector<DeviceInfoImpl> global_devices;
ContextImpl::currentContext is destroyed in the destructor
for the statically defined object __module, and relies on its
DeviceInfoImpl reference to query some hardware features while
being destroyed.
This means that we need to ensure that the global_devices vector is
destroyed affter __module, otherwise ContextImpl::currentContext's
DeviceInfoImpl reference will no longer be valid when __module is
destroyed.
Since these variables are all confined to a single compilation unit,
they will be destruct from bottom to top, so we need to make sure
that __module is the bottom definition so it can be destroyed first.
This bug was triggered by Buildroot autobuilders [1,2], causing this
kind of failures [3,4]:
[ 14%] Building CXX object modules/core/CMakeFiles/opencv_core.dir/src/system.cpp.o
/home/test/autobuild/instance-0/output/build/opencv-2.4.10/modules/core/src/system.cpp: In function '(static initializers for /home/test/autobuild/instance-0/output/build/opencv-2.4.10/modules/core/src/system.cpp)':
/home/test/autobuild/instance-0/output/build/opencv-2.4.10/modules/core/src/system.cpp:280:10: error: inconsistent operand constraints in an 'asm'
make[3]: *** [modules/core/CMakeFiles/opencv_core.dir/src/system.cpp.o] Error 1
[1] http://buildroot.org/
[2] http://autobuild.buildroot.org/
[3] http://autobuild.buildroot.org/?reason=opencv-2.4.10
[4] http://autobuild.buildroot.org/results/483/4838285b25d6293a5cf0bb9eadd5040a7c75d766/build-end.log
Signed-off-by: Samuel Martin <s.martin49@gmail.com>
Fixed the non-working code example for NAryMatIterator.
The documentation of NAryMatIterator in file:
modules/core/include/opencv2/core/core.hpp has a working example which
was used for these edits.
Currently, FFMPEG source files are included in highgui project file regardless of CMake WITH_FFMPEG option.
After applying this PR FFMPEG files are included only if WITH_FFMPEG option is enabled.
In C99 'inline' is not a hint to the compiler to inline the function,
it is an attribute that affects the linkage of the function. 'inline'
functions are required to have a definition in a different compiliation
unit, so compilers are free to delete 'inline' functions if they want to.
This issue can be seen in Clang when compiling at -O0. Clang
will sometimes delete 'inline' functions which creates an invalid
program.
Issue 3746: http://code.opencv.org/issues/3746
