- 11 Dec, 2014 1 commit
-
-
doltac authored
-
- 06 Dec, 2014 2 commits
-
-
Vadim Pisarevsky authored
-
Vadim Pisarevsky authored
-
- 05 Dec, 2014 1 commit
-
-
Jeremy Huddleston Sequoia authored
Fix tautologies in calibfilter.cpp which cause a build failure when using -Werror=address with clang-3.5 http://code.opencv.org/issues/4048Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
-
- 03 Dec, 2014 1 commit
-
-
Maksim Shabunin authored
-
- 01 Dec, 2014 2 commits
-
-
Vadim Pisarevsky authored
-
Vadim Pisarevsky authored
-
- 25 Nov, 2014 2 commits
-
-
Artur Wieczorek authored
There is necessary to account also x-ccordinate of the end of the edge when determining bounding box of the edge collection.
-
Vladislav Vinogradov authored
-
- 24 Nov, 2014 1 commit
-
-
Vadim Pisarevsky authored
-
- 19 Nov, 2014 1 commit
-
-
StevenPuttemans authored
-
- 16 Nov, 2014 3 commits
-
-
Vadim Pisarevsky authored
-
Vadim Pisarevsky authored
-
Vadim Pisarevsky authored
-
- 14 Nov, 2014 1 commit
-
-
StevenPuttemans authored
-
- 13 Nov, 2014 6 commits
-
-
Tom Stellard authored
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.
-
Vadim Pisarevsky authored
-
Roman Donchenko authored
It's needed for std::max.
-
Vadim Pisarevsky authored
-
Vadim Pisarevsky authored
-
Alexander Alekhin authored
-
- 12 Nov, 2014 6 commits
-
-
Samyak Datta authored
-
Maksim Shabunin authored
-
Ilya Lavrenov authored
-
Tom Stellard authored
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.
-
Roman Donchenko authored
-
StevenPuttemans authored
-
- 11 Nov, 2014 1 commit
-
-
Vadim Pisarevsky authored
-
- 10 Nov, 2014 2 commits
-
-
Roman Donchenko authored
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.
-
Vadim Pisarevsky authored
-
- 06 Nov, 2014 1 commit
-
-
Vadim Pisarevsky authored
-
- 05 Nov, 2014 3 commits
-
-
Vadim Pisarevsky authored
-
Vadim Pisarevsky authored
-
Samuel Martin authored
Using absolute path to locate the components in the "Libs:" field of the *.pc can badly break cross-compilation, especially when building statically linked objects. Indeed, pkg-config automatically replaces the '-I...' and '-L...' paths when the PKG_CONFIG_SYSROOT_DIR and PKG_CONFIG_LIBDIR environment variables are set [1]. This feature is very helpful and common in cross-compilation framework like Buildroot [2,3]. When there are absolute paths in the *.pc files, pkg-config won't be able to do the path substitions for these paths when the afromentioned environment variables are set. In such case, since the prefix is the target one, not the sysroot one, these libraries' abolute paths will point to: - in the best case: a non-existing file (i.e. these files do not exists on the host system; - at worst: the host system's libraries. This will make the linking failed because these host system's libraries will most likely not be build for the target architecture [4]. So, this patch replace the components' absolute paths by the form: -L<libdir> -l<libname> This way, the linker will be able to resolve each dependency path, whatever the kind of objects/build (shared object or static build) it is dealing with. Note that for static link, the library order does matter [5]. The order of the opencv components has been carefully chosen to comply with this requirement. Fixes #3931 [1] http://linux.die.net/man/1/pkg-config [2] http://buildroot.org/ [3] http://git.buildroot.net/buildroot/tree/package/pkgconf/pkg-config.in [4] http://autobuild.buildroot.net/results/e8a/e8a859276db34aff87ef181b0cce98916b0afc90/build-end.log [5] http://stackoverflow.com/questions/45135/linker-order-gccSigned-off-by: Samuel Martin <s.martin49@gmail.com> --- Note: this patch properly applies on top of the master branch, though it has been written on top of the 2.4 branch.
-
- 31 Oct, 2014 1 commit
-
-
Vadim Pisarevsky authored
-
- 30 Oct, 2014 1 commit
-
-
Vadim Pisarevsky authored
-
- 29 Oct, 2014 1 commit
-
-
StevenPuttemans authored
-
- 28 Oct, 2014 1 commit
-
-
StevenPuttemans authored
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.
-
- 27 Oct, 2014 2 commits
-
-
Vicente Olivert Riera authored
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.
-
Maksim Shabunin authored
-