Ask Your Question

Vadim Pisarevsky's profile - activity

2017-08-20 04:41:27 -0500 received badge  Great Answer (source)
2017-08-20 04:41:27 -0500 received badge  Guru (source)
2015-06-25 22:11:08 -0500 received badge  Necromancer (source)
2015-06-02 23:22:00 -0500 answered a question Opencv3 and Algorithm (create, getList, etc.)

Algorithm is not dead, it's more than alive; the algorithm "by-name" factory is dead because of multiple problems with it - non-guaranteed initialization, modules thrown away by linker, because it did not find any dependency of e.g. SIFT, big space overhead etc.

Well, if you like, do something like this in your code:

 typedef Ptr<Algorithm> (*algo_creator_t)();

 // proxy functions are needed since SIFT::create() etc. have optional parameters,
 // so the function pointers can not be unified.
 static Ptr<Algorithm> create_SIFT() { return SIFT::create(); }
 static Ptr<Algorithm> create_ORB() { return ORB::create(); }
 ...

 std::map<string, algo_creator_t> factory;
 factory["SIFT"] = create_SIFT;
 factory["ORB"] = create_ORB;
 ...

 string name = use_orb ? "ORB" : "SIFT";
 Ptr<Feature2D> obj = factory[name]().dynamicCast<Feature2D>();
2014-04-14 07:39:29 -0500 commented answer OpenCV 2.4.7 GPL Licensing Issue with mser.cpp

I think yes. In case if you want to play very safe, in the upcoming OpenCV 3.0 features2d will not include the current MSER code, so there will be no licensing issues.

2014-04-14 07:08:52 -0500 answered a question OpenCV 2.4.7 GPL Licensing Issue with mser.cpp

Thanks for raising this issue! In theory this is some violation of the license, of course, but this not a code, this is some relatively compact table, which can be easily reproduced using Excel, Matlab etc. So, it's not big problem, I think.

However, we (OpenCV team) always try to keep the library clean and so in the upcoming OpenCV 3.0 MSER code will be removed from the library until the clean implementation is ready. Meanwhile, we already have an efficient framework that analyzes all the extreme regions, not only maximally stable extreme regions (MSER's). It's called ERFilter (objdetect module). You are welcome to try it out.

2013-09-20 03:19:38 -0500 answered a question compiling opencv with yepp!

no plans. It's too little functionality in the library to bother

2013-03-08 03:55:28 -0500 received badge  Good Answer (source)
2013-02-28 01:42:35 -0500 received badge  Nice Answer (source)
2013-02-05 10:29:58 -0500 answered a question How Python API is generated?

We do not use SWIG or any other standard wrapper generation tool. We did not find such tools that would produce satisfying results.

Instead, we use our own purely Python-based solution for parsing OpenCV headers (we do not comprehend all the C++ syntax, just enough to extract declarations of the functions, classes, methods, as well as enumerations constants).

Since C/C++ API does not conveniently map to Python API (e.g. in Python we can have multiple return values, in C just one), we put in C++ headers some helper macros to give parser some high-level information about certain classes or method parameters. For example, CV_EXPORTS_W_MAP in the class declaration is equivalent to CV_EXPORTS for C++ compiler, but it instructs the header parser that the class should be converted to a Python map (dict) (which is very convenient for structures representing algorithm parameters).

The parser is at opencv/modules/python/src2/hdr_parser.py. BTW, our java wrapper generator uses the same technology and the same script to extract the API.

After all the API is extracted, we use some more python code (opencv/modules/python/src2/gen2.py) to produce Python wrappers. We created this script incrementally and used the concept of clear crisp wrapper code. In other words, instead of creating "for compiler eyes only" mess, we generate wrappers as if they were manually written. They are very easy to read, and therefore, it was not difficult to debug the wrapper generator.

For 2.5.x we plan to do some refactoring of the code, but we will continue to use this technology and are very happy with it. Besides the nice warm feeling that we have the full control over the result, the generator is also super-fast and does not impose any extra dependencies.

If you want to participate, it's enough to know C/C++, Python and a bit of the Python C API.

Another strict requirement is that you should not suggest us to switch to another wrapper generator, Boost-Python or whatever :)

2012-09-19 06:38:36 -0500 received badge  Necromancer (source)
2012-09-19 06:14:29 -0500 answered a question DCT coefficients in MPEG

It's not possible with OpenCV and it's out of the current scope of OpenCV. You can use ffmpeg or other similar library for accessing low-level information in video streams.

2012-09-19 06:09:10 -0500 answered a question Other free software with openCV

why not. VTK uses CMake, OpenCV uses CMake too. The simplest method would be to create a simple CMake script for your application and generate VS2010 project out of it.

2012-07-06 03:26:59 -0500 received badge  Guru (source)
2012-07-06 03:26:59 -0500 received badge  Great Answer (source)
2012-07-05 03:47:06 -0500 received badge  Enlightened (source)
2012-07-05 03:46:32 -0500 received badge  Good Answer (source)
2012-07-04 10:44:31 -0500 received badge  Nice Answer (source)
2012-07-04 10:28:18 -0500 received badge  Teacher (source)
2012-07-04 08:56:49 -0500 answered a question Which is more efficient, use contourArea() or count number of ROI non-zero pixels?

contourArea() uses Green formula (http://en.wikipedia.org/wiki/Green'stheorem) to compute the area, therefore its complexity is O(contournumberofvertices). Counting non-zero pixels in the ROI is O(roiwidth*roiheight) algorithm, i.e. much slower. Note, however, that because of finite, and quite low, resolution of the raster grid, the two algorithms will give noticeably different results. For large and square-like contours the error will be minimal. For small and/or oblong contours the error can be quite large.