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
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.
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.
Previously the Python3 cv2 package ends up with no submodules (bgsegm, face,
etc) in it, which makes a lot of functionality unusable. By not writing over
our root reference we ensure the new submodules are added to the correct cv2
module.
- Substituted HAVE_WINRT with WINRT
- Fixed compilation issues in ocl.cpp and parallel.cpp
- Fixed compiler issue for WP8: "C2678: binary '+' : no operator found which takes a left-hand - Fixed gitignore
- Added #ifdef HAVE_OPENCL to remove compiler warnings in ocl.cpp
- Used NO_GETENV similar to '3rdparty\libjpeg\jmemmgr.c;
- Added ole32.lib for core module (for WindowsStore 8.0 builds)
- Made OpenCV_ARCH aware of ARM
Signed-off-by: Maxim Kostin <v-maxkos@microsoft.com>
I had to make this modification locally to get opencv to build with python 2.6. Python 2.6 requires indices in the format string (the `0` I added). This requirement was relaxed in 2.7, so what used to be there would be working for people who could upgrade. I don't think the change has any negative consequences for future python versions, but I'm no expert.
The implicit narrowing in the initializer list throws a compiler error for some compilers with C++11 support turned on. The specific error message is: "error: narrowing conversion of 'PyInt_AsLong(((PyObject*)o))' from 'long int' to 'double' inside { }".
Tested on Clang 5.1.0 and Mac OS X 10.9.4.