Here is a solution that worked for me using boost.extension extensiblity library which is long deprecated but had it at my disposal. You can look into Microsoft's COM or Mozilla's XPCOM (Cross-platform COM) as an alternative to boost.extension. Probably better too.
Compiler packages: vc11 visual studio 12
OS: windows 7 x64 Integration
target: Legacy application with opencv 2.4.5
New version: opencv 3.3.1 - the dnn module in particular
The end solution was to write a wrapper\extension with network interface. This wraps API in COM server for version 3. The interface defines entry to opencv dnn stuff and is called by the legacy code that uses earlier version of opencv. Notice the interface makes no opencv3 references.
Interface :
// This is the dispatcher that gets statically linked to the legacy code
class IOpenCV3Interface
{
public:
typedef boost::shared_ptr<IOpenCV3Interface> ptr; // will be used by extension manager to load this class
virtual bool Classify(const char* data, const int &width, const int &height)
}
In legacy code we use boost extension manager to instantiate this object and call classify:
IOpencv3Interface::ptr _opencv3Interface = ExtensionFinder<IOpencv3Interface>().CreateSingle()
_opencv3Ingerface.Classify(data,10,10)
at this point a call to opencv 3 is on its way
Now have a derived class implement classify which uses opencv stuff.
//This gets loaded by the dispatcher dynamically using boost.extension manager
class Classifier : IOpenCV3Interface
{
public:
bool Classify(const char* data, const int& w, const int& h) override;
}
clasifier.cpp
Classifer::Classify(const char* data, const int& w, const int &h)
{
//use open cv 3.
}
This approach essentially decouples the two libraries by adding the opencv 3 code as a plugin. Compiler is okay with this so far. I'll update the answer if anything changes
Let me know if you have any questions
One way would be to make two wrapper DLLs that act as a buffer between your code and the OpenCV code. That way you can build one version into one DLL, and build the other version into the other DLL. None of your current redefinition problems will occur. Writing a DLL is not very hard -- Visual Studio has a template DLL project even.
Another way would be to write just one DLL, and build one version into it, and then build the other version directly into the exe file. In this case I'd make the DLL encapsulate the newest version of OpenCV, since that's the API that you work the least with (you only have to encapsulate the DNN functionality).
It's your call.
On second thought, this solution might not work at first. I'm using VS Community 2017 (VC19), and I had no problem making the DLL file, but when I add code that uses the OpenCV library, I get linker errors; undefined references.
I put the DLL wrapper code at: https://github.com/sjhalayka/OpenCV3_...
I put the DLL wrapper user code at: https://github.com/sjhalayka/OpenCV3_...
It looks like you might have to also encapsulate the Mat class, or better yet, just pass around the raw image data between the exe (wrapper user) and the DLL (wrapper). I'll play around with it for a bit more to see what I come up with.
Thanks a bunch for your help. What you described above, option 2, is what I'm leaning towards as well. I'll be expecting a cv::Mat or just buffer of pixels from legacy code and do transform\convert to cv::Mat before passing input through network.
Hi again, I fixed the wrapper and wrapper user code. They pass around a vector<float> by reference, to store floating-point image data. You can grab a pointer to the vector's memory block by using the address-of operator
So the Mat constructor (in your OpenCV 2.x code) would be
My GitHub repositories listed above are using option #2.
P.S. If you come up with a solution, write about it as an answer to this question.
Thanks my friend. I'm pretty much using what you have, except I need char* instead of vector<float>. Cross fingers :-( Will close the case for now.
Alright, well let us know if you need help with anything else. It was a fun project to work on. :)