Vadim Pisarevsky's profile - activity

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>();

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.

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.

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

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 :)

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.

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.

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.