Ask Your Question

Opencv3 and Algorithm (create, getList, etc.)

asked 2014-10-23 00:48:19 -0500

updated 2020-11-30 00:51:20 -0500

Hi, I just moved my project from 2.4.9 to 3.0.0alpha and I noticed that most of feature2d algorithms don't use the macro the CV_INIT_ALGORITHM which allows us to use:

cv::Ptr<FeatureDetector> detect = FeatureDetector::create<FeatureDetector>("SIFT");

My project highly relies on such feature (and also on get/set parameter, list algos and parameters...), so my question is : will this feature included in OpenCV3 or Algorithm is going to be a dead-end ?

edit retag flag offensive close merge delete


hmm, features2d_init.cpp, calib3d_init.cpp and video_init.cpp all 'vanished' lately..

berak gravatar imageberak ( 2014-10-23 02:18:25 -0500 )edit

Indeed! You can just see in commits logs : "OpenCV with the refactored features2d compiles!", but I don't find an explanation why they refactored features2d, calib3d and optical flow algorithms...

petititi gravatar imagepetititi ( 2014-10-23 03:33:06 -0500 )edit

I had the same issues. Plus the fact that I rely a lot exactly in the re-factored algorithms and the ones that was moved away from the main code. This broke compatibility of a quite complex project of mine. A pity, considering that the transition from 2.4.2 up to 2.4.9 was for me mostly seamless.

R.Saracchini gravatar imageR.Saracchini ( 2014-10-24 04:41:18 -0500 )edit

i could even understand, if they're trying to get rid of cv::Algorithm, - imho pure virtual interfaces + factory function + hidden class impl is much cleaner / more robust than having a 'super' base class, which requires virtual inheritance.

berak gravatar imageberak ( 2014-10-24 05:27:02 -0500 )edit

3 answers

Sort by ยป oldest newest most voted

answered 2015-06-02 13:42:15 -0500

Vadim Pisarevsky gravatar image

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>();
edit flag offensive delete link more


Why create pointers to Algorithm and casting to Feature2D instead of directly dealing with pointers to Feature2D?

nschejtman gravatar imagenschejtman ( 2018-03-20 13:32:54 -0500 )edit

answered 2014-11-05 09:54:01 -0500

A small bump as this is not yet answered... Maybe someone know how to list every feature2d algorithms the user has access to (at run-time of course), without Algorithm::getList()?

edit flag offensive delete link more

answered 2014-11-11 13:42:57 -0500

cv_user gravatar image

I'd also like to know what is happening here?

I can't find the "initModule..." anywhere. Algorithm::getList() only shows 2 algorithms. What is going on?

edit flag offensive delete link more

Question Tools

1 follower


Asked: 2014-10-23 00:48:19 -0500

Seen: 1,289 times

Last updated: Nov 30 '14