.Net (Dotnet) Wrappers for Opencv

.Net (dotNet) wrappers for OpenCV?

I started out with opencvdotnet but it's not really actively developed any more. Further, support for the feature I needed (facedetection) was patchy. I'm using EmguCV now: It wraps a much greater part of the API and the guy behind it is very responsive to suggestions and requests. The code is a joy to look at and is known to work on Mono.

I've wrote up a quick getting-started guide on my blog.

Are .Net OpenCV wrappers worth using?

I have not used EmguCV, but I have used OpenCV for a while now.

From SharperCV's website:

The Emgu CV.Net wrapper is our current recommendation if you want to use OpenCV.

And, OpenCVDotNet looks more like an academic sandbox, so if it were me, I would use EmguCV for any of my research projects that involved C#. Mainly because it is being actively maintained, and it has the most features of the available wrappers today.

Is there any wrapper for OpenCV for .net core on linux

I ended up with OpenCvSharp, it fills my requirements.

C++ opencv app in C# window

Maybe you should take a look at this other thread:

.Net (dotNet) wrappers for OpenCV?

It may be easier to use a wrapper of OpenCV for your case.

Creating simple c++.net wrapper. Step-by-step

http://www.codeproject.com/KB/mcpp/quickcppcli.aspx#A8

This is general direction. You need to create C++/CLI Class Library project, add .NET class to it (StudentWrapper in this sample), create unmanaged class instance as managed class member, and wrap every unmanaged class function. Unmanaged library is added to C++/CLI project using linker dependencies list, and not as reference. In the Project - Properties - Linker open Additional Dependencies and add .lib name there.

Note: since we are talking about C++/CLI wrapper, no PInvoke! PInvoke is used to call exported functions (API), and not classes.

Computer Vision Library

A friend of mine has used OpenCV.net (a C# wrapper for OpenCV) for his Master's thesis (which was about hand gesture recognition) and found it very well developed and easy to use.

Using OpenCV library in VB.NET project

First this: https://www.nuget.org/packages/OpenCV.Net/
and then replace your 'using ??' with: Imports OpenCV.Net

Wrapping C++ for use in C#

As a rule, the C/C++ structs are used for communicating with the native code, while you create CLI classes for communicating with the .NET code. C structs are "dumb" in that they can only store data. .NET programmers, on the other hand, expect their data-structures to be "smart". For example:

If I change the "height" parameter in a struct, I know that the height of the object won't actually change until I pass that struct to an update function. However, in C#, the common idiom is that values are represented as Properties, and updating the property will immediately make those changes "live".

That way I can do things like: myshape.dimensions.height = 15 and just expect it to "work".

To a certain extent, the structures you expose to the .NET developer (as classes) actually ARE the API, with the behaviors being mapped to properties and methods on those classes. While in C, the structures are simply used as variables passed to and from the functions that do the work. In other words, .NET is usually an object-oriented paradigm, while C is not. And a lot of C++ code is actually C with a few fancy bits thrown in for spice.

If you're writing translation layer between C and .NET, then a big part of your job is to devise the objects that will make up your new API and provide the translation to your underlying functionality. The structs in the C code aren't necessarily part of your new object hierarchy; they're just part of the C API.

edit to add:

Also to Consider

Also, you may want to re-consider your choice to use C++/CLI and consider C# and p/invoke instead. For various reasons, I once wrote a wrapper for OpenSSL using C++/CLI, and while it was impressive how easy it was to build and how seamless it worked, there were a few annoyances. Specifically, the bindings were tight, so every time the the parent project (OpenSSL) revved their library, I had to re-compile my wrapper to match. Also, my wrapper was forever tied to a specific architecture (either 64-bit or 32-bit) which also had to match the build architecture of the underlying library. You still get architecture issues with p/invoke, but they're a bit easier to handle. Also, C++/CLI doesn't play well with introspection tools like Reflector. And finally, the library you build isn't portable to Mono. I didn't think that would end up being an issue. But in the end, I had to start over from scratch and re-do the entire project in C# using p/invoke instead.

On the one hand, I'm glad I did the C++/CLI project because I learned a lot about working with managed and unmanaged code and memory all in one project. But on the other hand, it sure was a lot of time I could have spent on other things.

---

Related Topics