OpenCV
4.5.1
Open Source Computer Vision
|
Prev Tutorial: Writing documentation for OpenCV
Next Tutorial: Cross referencing OpenCV from other Doxygen projects
Original author | Maksim Shabunin |
Compatibility | OpenCV >= 3.0 |
This document is intended to software developers who want to migrate their code to OpenCV 3.0.
OpenCV 3.0 introduced many new algorithms and features comparing to version 2.4. Some modules have been rewritten, some have been reorganized. Although most of the algorithms from 2.4 are still present, the interfaces can differ.
This section describes most notable changes in general, all details and examples of transition actions are in the next part of the document.
https://github.com/opencv/opencv_contrib
This is a place for all new, experimental and non-free algorithms. It does not receive so much attention from the support team comparing to main repository, but the community makes an effort to keep it in a good shape.
To build OpenCV with contrib repository, add the following option to your cmake command:
In 2.4 all headers are located in corresponding module subfolder (opencv2/<module>/<module>.hpp), in 3.0 there are top-level module headers containing the most of the module functionality: opencv2/<module>.hpp and all C-style API definitions have been moved to separate headers (for example opencv2/core/core_c.h).
General algorithm usage pattern has changed: now it must be created on heap wrapped in smart pointer cv::Ptr. Version 2.4 allowed both stack and heap allocations, directly or via smart pointer.
get and set methods have been removed from the cv::Algorithm class along with CV_INIT_ALGORITHM macro. In 3.0 all properties have been converted to the pairs of getProperty/setProperty pure virtual methods. As a result it is not possible to create and use cv::Algorithm instance by name (using generic Algorithm::create(String) method), one should call corresponding factory method explicitly.
This section describes concrete actions with examples.
Some changes made in the latest 2.4.11 OpenCV version allow you to prepare current codebase to migration:
Note: Changes intended to ease the migration have been made in OpenCV 3.0, thus the following instructions are not necessary, but recommended.
initModule_<moduleName>()
callsSince this module has been rewritten, it will take some effort to adapt your software to it. All algorithms are located in separate ml namespace along with their base class StatModel. Separate SomeAlgoParams classes have been replaced with a sets of corresponding getProperty/setProperty methods.
The following table illustrates correspondence between 2.4 and 3.0 machine learning classes.
2.4 | 3.0 |
---|---|
CvStatModel | cv::ml::StatModel |
CvNormalBayesClassifier | cv::ml::NormalBayesClassifier |
CvKNearest | cv::ml::KNearest |
CvSVM | cv::ml::SVM |
CvDTree | cv::ml::DTrees |
CvBoost | cv::ml::Boost |
CvGBTrees | Not implemented |
CvRTrees | cv::ml::RTrees |
CvERTrees | Not implemented |
EM | cv::ml::EM |
CvANN_MLP | cv::ml::ANN_MLP |
Not implemented | cv::ml::LogisticRegression |
CvMLData | cv::ml::TrainData |
Although rewritten ml algorithms in 3.0 allow you to load old trained models from xml/yml file, deviations in prediction process are possible.
The following code snippets from the points_classifier.cpp
example illustrate differences in model training process:
Some algorithms (FREAK, BRIEF, SIFT, SURF) has been moved to opencv_contrib repository, to xfeatures2d module, xfeatures2d namespace. Their interface has been also changed (inherit from cv::Feature2D
base class).
List of xfeatures2d module classes:
Following steps are needed:
opencv2/xfeatures2d.h
headerxfeatures2d
operator()
calls with detect
, compute
or detectAndCompute
if neededSome classes now use general methods detect
, compute
or detectAndCompute
provided by Feature2D
base class instead of custom operator()
Following code snippets illustrate the difference (from video_homography.cpp
example):
All specialized ocl
implementations has been hidden behind general C++ algorithm interface. Now the function execution path can be selected dynamically at runtime: CPU or OpenCL; this mechanism is also called "Transparent API".
New class cv::UMat is intended to hide data exchange with OpenCL device in a convenient way.
Following example illustrate API modifications (from OpenCV site):
CUDA modules has been moved into opencv_contrib repository.
Documentation has been converted to Doxygen format. You can find updated documentation writing guide in Tutorials section of OpenCV reference documentation (Writing documentation for OpenCV).
In some cases it is possible to support both versions of OpenCV.
To check library major version in your application source code, the following method should be used:
It is possible to link different modules or enable/disable some of the features in your application by checking library version in the build system. Standard cmake or pkg-config variables can be used for this:
OpenCV_VERSION
for cmake will contain full version: "2.4.11" or "3.0.0" for exampleOpenCV_VERSION_MAJOR
for cmake will contain only major version number: 2 or 3Version
Example: