I am using Qt & OpenCV on a new project am about to compile OpenCV to work with MinGW.
A thought has arose that I can compile the OpenCV libs with Qt support but I don't really understand why I would want to do that. If I don't compile the libs with Qt support I can still route cv::mat to a QImage using a method like this.
So what am I missing? What value is provided in compiling Qt with OpenCV?
I have searched online and pages like this, this & this (from searching "why compile OpenCV with Qt") only show me how to compile with Qt and not why.
LE: misunderstood the question
WITH_QT option is used by highgui module to create windows using qt, so the QImage to cv::Mat conversion and vice-versa will work no matter how WITH_QT option is set.
First some clarifications: you are not compiling OpenCV with Qt, Qt is not a compiler so you can't compile anything with it.
Qt is a C++ library (it's called a framework because it imposes some design some rules to your application source code, but basically it's a C++ library, just like OpenCV).
Now, in C++ world* to use some libraries together you need to build those libraries with the same compiler (and in some cases even the same compiler settings), so must decide which C++ compiler you want to use and get both Qt and OpenCV built with the same compiler not necessarily build by you, binaries can be obtained from their websites.
If you want to use MinGW you will need to build OpenCV with MinGW compiler, because OpenCV (at least, version 2410) comes build only with Visual C++ version 10, 11, 12 - that means Visual Studio 2010, 2012 and 2013.
So if you decide to use some Visual Studio version, depending on version you choose, you might be able to use Qt with OpenCV without having to build neither yourself, but if you want MinGW compiler you need to build OpenCV with MinGW.
*you can get away with it if your libraries only export a C interface, but that is not the case with neither Qt nor latest OpenCV versions.
//if you want more details about this use your favorite internet search engine to search for: c++ binary compatibility and or c++ abi
You'd like to compile OpenCV with Qt for at least two reasons:
it gives you the zoom (mouse wheel) in imshow
it gives you the pixel RGB value when hovering over this pixel
Without WITH_QT, you just have a bare window, with none of these features (and you'll miss extra buttons too, like Save the picture), which make the image processing debugging more tedious.
Related
My problem is the same as in:
OpenCV GTK+2.x error
I am facing this problem deploying my code in systems where OpenCV is available but has not been installed with GTK support. I have no control over OpenCV installation in these systems.
How can I discriminate where OpenCV is compiled without GTK support from C++ code, possibly without relying on catching exceptions? I would simply avoid calling imshow in these cases.
you could check dependencies by executing ldd opencv-lib and parse the output using e.g. regex to check for some kind of gtk libs.
Or use this approach: linux/gcc: ldd functionality from inside a C/C++ program
setenv("LD_TRACE_LOADED_OBJECTS", "1", 1);
FILE *ldd = popen("/lib/libz.so");
Say I have a open source C::B C++ (non-C++11, perfectly compatible with the 1998 ISO standard) project I've downloaded which is using MinGW/GCC (TDM-1 4.7.1 or 4.7.2 - doesn't work with newest version),; can I port the source files from it to Visual Studio 2010 and be able to make it work without massive code rewriting? Or there are certain cases in which it won't be possible? Or it depends on various things?
EDIT:
The code relies on additional external utilities and libraries such as:
Lua
SDL 2.0 + SDL Image 2.0
OpenGL
The most General and correct response is: It depends on various things.
What kind of project are you refering to? Is it wxWidget, QT4, GTK+, OpenGL?
How much do you use c++11?
Assuming that we are talking about a simple Console Application the easiest way to verify whether you can migrate to MSVC2010 is to switch compiler inside Code::Blocks project.
Select Project->Build Option... and under Selected compiler choose Microsoft Visual Studio C++ 2010. Afterwards try to recompile. The warning and errors will show you how easy will be the porting.
Of course you have to install Code::Blocks with MSVC2010 too.
EDIT: The OpenGL library is supported by MSVC2010 and libsdl has VC development libraries. However, things seem to be more complex with Lua. My guess is that you might start a substantial porting work here.
If the project was written using portable C++98 code you shouldn't have too much trouble. First, I would check you can compile in GCC with -std=c++98 -pedantic flags and fix any warnings to ensure you are not relying on any GCC extensions.
It also depends on the portability of any required libraries.
Try it!
If your code is standard-compliant and does not rely on any GCC extensions or GCC-specific libraries, then you should be fine out-of-the-box.
Note though that different compilers support C++ in different ways; for example, even Visual Studio 2013 has only passing C++11 support so if your program is a C++11 program with things like ranged-for and initializer lists in it then, depending on the version you're using, it's just not going to work without those pieces of code being rewritten to look more like C++03.
I actually made a mistake:
C::B indeed told me there were multiple errors in the compilation attempt with the MSVC2010 compiler, because the code included many Unix-only libraries, too intricately so to be easily avoided. Thus, I'm thinking of either making MinGW/GCC work in Visual Studio itself or sticking with C::B.
(Continues here: POSIX Headers (from MinGW project) in Visual Studio 2013)
I wrote cpp code using OpenCV library, compiled it with cmake and everything works good on Ubuntu. Now I need to compile the same code for Windows 7 or higher. I have no experience with cross compiling, is there any at least relatively easy and reliable way how to do it? Probably somehow change the CMakeLists or so?
Building OpenCV library for Windows seems according official tutorial pretty demanding.
I am working with OpenCV 2.4.9 under Windows 8.1 x64. I am trying to run basic operations like image reading, webcam streaming, etc. I've configured OpenCV to work with VS and QtCreator.
In both cases I use precompiled binaries from the x64/vc12 OpenCV folder, built with the VC compiler version 12.0. In Visual Studio everything works great in both release and debug modes, but in Qt Creator only release mode works correctly while in debug mode I encounter strange bugs like: wrong windows titles, imread not working correctly, bad video streaming.
In Qt Creator I use the same compiler as in VS, namely vc12. I've setup the library paths correctly and am using debug version of libs for debug and appropriate ones for release.
The problems only arise when I am using C++ API in OpenCV, everything works fine if I am using the C API.
I've seen problems like mine arise regularly one, two, three, but none of those solutions solve my problem.
UPDATE: Problem solved, see the answer below.
Problem solved!
It was in the Qt Creator's qmake, it did not correctly update the Makefile that it generates. So, instead of debug versions of the libraries, the release versions were used, but the .pro file in the project showed just the opposite.
Many functions in the latest release of OpenCV require the use of STL containers. I run into problems when trying to use them in a Matlab MEX file. I am compiling the MEX files from within Matlab. Both OpenCV and Matlab use the "/MD" flag which is "Multithreaded DLL" for code generation.
Compiler: MSVC++ 9.0
Matlab 2010a
OpenCV latest from SVN, 2.11 I think.
The code I am using is very simple:
vector<KeyPoint> keypoints_vec;
SurfFeatureDetector surf;
surf.detect(cvImg,keypoints_vec);
This compiles but crashes when run in a Matlab MEX file. The crash is within OpenCV in vector::resize. The old interface (without STL containers) works fine but is deprecated. How can I use STL containers between Matlab and OpenCV?
I fought with this very problem in the last two days. The problem is this:
libmex.dll (and a whole Matlab) uses Microsoft.VC80.CRT (version=8.0.50727.4053)
But your OpenCV uses Microsoft.VC90.CRT (version=9.0.21022.8)
So you can use the previous version of VC (VS 2005 with SP1 as far as I know), or as a workaround, you can use gcc (MINGW) (in this case they use totally different stl, so they can't interfere).
I did the latter and it works, and it will work with the next versions of Matlab (hopefully).
A long time ago I had problems with Matlab <-> VS interop. It might be some microsoft visual c++ runtime library discrepancy. Check what runtime lib is required by matlab and what version does your visual studio have. I remember using Depends to get the dll dependencies for my program. Check your call stack after crashing (by attaching your msdev debugger) it might give you some hints.
It was a long time ago so I'm just giving hints of what I remember.
I had a similar problem in the past few days, and was able to resolve the issue with some help from the friendly folks at MathWorks.
From the original post at http://www.mathworks.com/matlabcentral/answers/9294-mex-dynamic-memory-management-issue-with-std-vector-in-linked-external-dll-segmentation-error :
You are probably seeing an incompatibility between the stl library and or compiler options used by your pre-compiled dll and those used by MATLAB and the MEX command. MATLAB 2009b was built with MSVC 2005.
You may be able to fix the problem by changing the options used by mex or by building your mex file directly with MSVC. One example of an option that may effect things is SECURE_SCL=0. I would start by building your test program with the options MATLAB is using to find the problematic option then try removing that option when building the mex file.
Because of this sort of incompatibility use of stl objects in the api's of third party compiled libraries is usually a bad idea.
Following his advice, I removed the SECURE_SCL=0 option from the mex options file at
C:\Users\ThePit\AppData\Roaming\MathWorks\MATLAB\R2009b\mexopts.bat
Then recompiled the mex file, now everything works like a charm - the function is returning the correct data and segmentation error no longer occurs.
The data in a vector should still be stored as a single contiguous block
std::vector<int> data;
int *array = &data[0];
int *array = &data.front();
Should give you 'c' style pointers to the data, try passing these to matlab
see also: How does the C++ STL vector template store its objects in the Visual Studio compiler implementation?