Home » U++ Library support » Draw, Display, Images, Bitmaps, Icons » OpenCV
| OpenCV [message #32614] |
Sat, 28 May 2011 08:49  |
|
|
When trying to build program with subj I get numerous "ambiguous symbol" errors in opencv2/core/types_c.h and uppsrc\Core/Defs.h files.
How do I fix it? Plus, maybe there are some practices using algorithms from OpenCV in U++?
|
|
|
|
|
|
| Re: OpenCV [message #32646 is a reply to message #32614] |
Tue, 31 May 2011 08:10   |
|
|
Well, as far as I can see in given example only opencv v1 was used. I use 2.2 (opencv2 API).
No fuctional yet, just exploring:
#include <opencv2/opencv.hpp>
#include <CtrlLib/CtrlLib.h>
using namespace Upp;
void proto1::FileOpenClick()
{
selectDlg.ExecuteOpen();
IplImage* img = cvLoadImage(~selectDlg);
}
Gives erros:
| Quote: | c:\upp\uppsrc\core\config.h(97) : warning C4005: '_CRT_SECURE_NO_DEPRECATE' : macro redefinition
C:\OpenCV2.2\include\opencv2/core/types_c.h(47) : see previous definition of '_CRT_SECURE_NO_DEPRECATE'
C:\MyApps\proto1\main.cpp(20) : error C2040: 'img' : 'IplImage *' differs in levels of indirection from 'Upp::Image'
|
|
|
|
|
|
|
|
|
| Re: OpenCV [message #32694 is a reply to message #32690] |
Thu, 02 June 2011 10:17   |
|
|
Very interesting,
But I am a little confused. What library is better to use for 2d and 3d acceleration.
From practice can somebody tell what to recommend?
|
|
|
|
|
|
| Re: OpenCV [message #32698 is a reply to message #32696] |
Thu, 02 June 2011 11:57   |
|
|
| koldo wrote on Thu, 02 June 2011 12:29 |
Hello Ion
I do not understand you. OpenCV is used for image processing.
You open images or real time video and process it, extracting the info you want.
It also accepts stereo images and lets you calibrate the camera and spatially position picture elements as in photogrametry.
|
From my question "2d and 3d acceleration" is a little confuse.
I mean that exist other libraries for image processing which uses gpu acceleration.
It is better to uses some optimized library than reinventing the wheel. In my example about reinventing the wheel was how to autolevel/autocorect an image.
And question:
From your experience what library is the recommended for use in image processing?
|
|
|
|
| Re: OpenCV [message #32700 is a reply to message #32698] |
Thu, 02 June 2011 13:06   |
 |
koldo
Messages: 3458 Registered: August 2008
|
Senior Veteran |
|
|
Hello Ion
OpenCV is recognized as the fastest. See for example this comparison taken from the "Learning OpenCV" book. The number of users is also very high.
Added:
However fastest is not always the best. In my case OpenCV camera calibration functions do not calibrate properly the cameras I use...
Best regards
Iñaki
[Updated on: Thu, 02 June 2011 13:52] Report message to a moderator
|
|
|
|
Re: OpenCV [message #32713 is a reply to message #32700] |
Fri, 03 June 2011 01:07   |
|
|
There is "gpu" subfolder in lib, but I didn't have the time to look into it yet. Some structures and routines are definetly already there. Can't say what they do though 
BTW, have another noob question, a bit offtopic though. When I include <opencv22/opencv2/opencv.hpp>, everything else is included recursively and builds fine, but not everything is found by Ctrl+Space, e.g. if I try to explore "cv" namespace, I try typing "cv::" and press Assist shortcut, but get nothing. By just pressing shortcut, I don't even see "cv" namespace in the list. Once again, why?
[Updated on: Fri, 03 June 2011 04:31] Report message to a moderator
|
|
|
|
|
|
| Re: OpenCV [message #32718 is a reply to message #32700] |
Fri, 03 June 2011 09:06   |
|
|
| koldo wrote on Thu, 02 June 2011 14:06 | Hello Ion
OpenCV is recognized as the fastest. See for example this comparison taken from the "Learning OpenCV" book. The number of users is also very high.
Added:
However fastest is not always the best. In my case OpenCV camera calibration functions do not calibrate properly the cameras I use...
|
Thank you Koldo!
|
|
|
|
| Re: OpenCV [message #32720 is a reply to message #32713] |
Fri, 03 June 2011 09:34   |
|
|
| GaroRobe wrote on Fri, 03 June 2011 01:07 | BTW, have another noob question, a bit offtopic though. When I include <opencv22/opencv2/opencv.hpp>, everything else is included recursively and builds fine, but not everything is found by Ctrl+Space, e.g. if I try to explore "cv" namespace, I try typing "cv::" and press Assist shortcut, but get nothing. By just pressing shortcut, I don't even see "cv" namespace in the list. Once again, why? 
|
It is quite simple The parser in theide ignores namespaces completely. It is a tradeof to get the parsing faster. You should be able too see most of the methods (classes, variables, macros, etc...) by just skipping the namespace part. Unless the code is too cryptic, uses macros extensively, or something like that, that the parser chokes on, but that doesn't happen too often.
Honza
|
|
|
|
| Re: OpenCV [message #32723 is a reply to message #32720] |
Sat, 04 June 2011 07:12   |
|
|
Don't quite understand. What do you mean "skipping the namespaces"?
Well, it seems that OpenCV C++ API is right that "too cryptic" case. Take, for example, cv::calibrateCamera method. I might use cvCalibrateCamera (OpenCV C API), but I, peronally, find such decisions inconsistent - I use C++ because I want to use it, not because I can use C syntax in it.
|
|
|
|
| Re: OpenCV [message #32724 is a reply to message #32723] |
Sat, 04 June 2011 08:31   |
|
|
| GaroRobe wrote on Sat, 04 June 2011 07:12 | Don't quite understand. What do you mean "skipping the namespaces"?
Well, it seems that OpenCV C++ API is right that "too cryptic" case. Take, for example, cv::calibrateCamera method. I might use cvCalibrateCamera (OpenCV C API), but I, peronally, find such decisions inconsistent - I use C++ because I want to use it, not because I can use C syntax in it.
|
By "skipping namespaces" I meant just not typing them E.g. type just calibrat and Assist should show calibrateCamera. It works as if there was always appropriate using namespace ... even when there isn't 
Honza
|
|
|
|
|
|
| Re: OpenCV [message #32733 is a reply to message #32729] |
Sat, 04 June 2011 17:14   |
|
|
Ok, my bad... Now I actually looked at the package and it is all clear Sorry for misleading you before.
The way the package is constructed, it uses libraries and include files from outside of U++. And Assist++ parser only reads the files that are present in the packages. That is another trade-off for speed, parsing all the system headers would be very slow.
Also, while I was looking at the pacakge, I fixed it to compile and link on Linux, but I get a lot of memory leaks. Looking at the valgrind output, it seems that most of them is associated with gtk functions. My guess is that the opencv windowing functions (like cvNamedWindow) are to be blamed. It would be probably better to find a way to export the images to Upp::Image and handle all the GUI using U++. I haven't time to do that so far though...
Best regards,
Honza
|
|
|
|
| Re: OpenCV [message #32734 is a reply to message #32733] |
Sun, 05 June 2011 02:26   |
|
|
I'll look into ways to import/export later, for now I compile mainly in win32 with msvc10 - it's the main target platform FOR NOW anyway. But lacking assist is really annoying.
Well what do we have:
1. Assist++ works good dynamically in most cases.
2. Assist++ fails in some obscure cases which are much-much-more less frequent, but sometimes annoying as hell.
My point is...:
3. Why not have an additional functionality for packages in form of Assist++ hinting dictionaries?
Make it so that package maintainers might make such dictionaries (say, "func prototype"/"header"[-"string#"][/"src"[-"string#"]][/ "descr"]) and assist would attach 'em to its list once when package is attached and the rest of A++ would work dynamically like it does now.
I really don't know A++ internals and don't really understand all the problems following names parsing, but such function would be, to my mind, a decent tradeoff.
|
|
|
|
| Re: OpenCV [message #32738 is a reply to message #32734] |
Sun, 05 June 2011 07:02   |
 |
koldo
Messages: 3458 Registered: August 2008
|
Senior Veteran |
|
|
Hello Honza
It would be probably better to find a way to export the images to Upp::Image and handle all the GUI using U++. I haven't time to do that so far though...
No problem. As I did not like OpenCV windowing system (HighGui) I included in OpenCV a U++ image window class and functions to convert images from/to U++ and OpenCV .
Go to:
IplImage *ImageToCv(Image &img, bool iscolor = false);
Image CvToImage(IplImage *imgCV);
class ImageWindow;
Best regards
Iñaki
[Updated on: Sun, 05 June 2011 07:07] Report message to a moderator
|
|
|
|
|
|
| Re: OpenCV [message #32746 is a reply to message #32734] |
Sun, 05 June 2011 22:36   |
|
|
| GaroRobe wrote on Sun, 05 June 2011 02:26 | 3. Why not have an additional functionality for packages in form of Assist++ hinting dictionaries?
Make it so that package maintainers might make such dictionaries (say, "func prototype"/"header"[-"string#"][/"src"[-"string#"]][/ "descr"]) and assist would attach 'em to its list once when package is attached and the rest of A++ would work dynamically like it does now.
|
That is actually quite good idea It should be even relatively easy to implement. There is already one "backdoor" to feed information to Assist++ or to hide it, the parser directives //$, //$- and //$+. If we can get the description of the entire OpenCV API in C++ syntax, dumped in one file and prefixed with //$, it should make the Assist work. Of your course better (faster) solution would be to store the pre-parsed data, but the parser is quite fast, maybe it wouldn't even be necessary...
Honza
|
|
|
|
| Re: OpenCV [message #32748 is a reply to message #32746] |
Mon, 06 June 2011 01:41   |
|
|
I'll look into it immidiately.
Okay, what I managed to dig so far is that A++ fails to parse prototypes with macroes in function arguments, e.g.:
//$ void foo( MY_DEFINE int bar )
fails, while
works.
OpenCV is tangled with CV_[SOMETHING] inside out, so it's quite a headache and calls for some intensive sed and awk usage .
Moreover, that's not the only one case:
//$ CV_EXPORTS void RQDecomp3x3 ( const Mat& M, Mat& R, Mat& Q );
Works.
//$ CV_EXPORTS_W Vec3d RQDecomp3x3 ( const Mat& M, Mat& R, Mat& Q, Mat& Qx, Mat& Qy, Mat& Qz );
Fails.
Don't get the reason.
[Updated on: Mon, 06 June 2011 02:43] Report message to a moderator
|
|
|
|
|
|
|
|
| Re: OpenCV [message #33036 is a reply to message #32614] |
Mon, 04 July 2011 02:12  |
|
|
|
Okay, enough of being full of myself - I will find neither time nor bravery to start solving this problem so I do what might solve it - just ask for your help. Anyone who can comprehend solution completely, please, post here everything related - this feature would be really useful when start working with completely foreign API.
|
|
|
|
Goto Forum:
Current Time: Mon Apr 27 20:18:58 GMT+2 2026
Total time taken to generate the page: 0.02049 seconds
|