I read latest Opencv roadmap presentation and I'd like to have some more info on c# bindings.
I'd like to know if they will be shipped with final Opencv 3.0 release or not. It would be also interesting to know if it will be a simple wrapper or more object oriented following the approach proposed by EmguCV.
Unfortunately we don't have plans to release C# support in the 3.0 release, because nobody is working on it. So, you should probably continue to use EmguCV. It is not an "official" wrapper, but it seems that it is stable enough, and it provides good support.
And here is some more information about the C# support in OpenCV. There was an attempt to enable the use of OpenCV from Mono/.NET, see https://github.com/Itseez/opencv/pull/604 . This wasn't yet merged, since it needs some improvements, but guys may finish it by the 3.0 release. It is not exactly what is asked, but it actually allows you to call OpenCV from C#.
And I think that we'll have "simple wrapper", simply because we don't want to have/maintain two versions of API. All OpenCV wrappers are autogenerated from the C++ one, and this is good.
Of course in some languages [almost] everything is a class, like in Java or C#. And yes, in Java we have Core and Imgproc classes, that encapsulate free functions. We'll have something like that in C#. But we will not design a separate hierarchy of classes for every language, otherwise it will be impossible to maintain (keep aligned with evolving default C++ API).
Finally, OpenCV itself will become more object-oriented (in some sense). You're probably familiar with the cv::Algorithm concept, and all the new functionality will likely be organized this way. The library will remain flat, no deep nested namespaces and complicated class hierarchies, but all high-level algorithms will be classes. We hope that such design will simplify the library usage, and it will be reflected in the wrappers.
@Kirill Kornyakov: link not working for the pull request :)
Thanks a lot Kirill for your detailed explanation. As you underline, latest opencv c++ api is really more OO, so it makes sense to simply wrap it. EmguCV is really good but one of its major issues is licensing. I agree with you on your performance concerns about using IKVM + JNI calls. It' just an idea but maybe the best strategy could be the one defined by sharpdx, i.e create a tool to autogenerate wrapper from opencv headers.
Maybe it could be an interesting project to insert into gsoc2014 :-)
Just want to add that I use EmguCV at work and the Library is very well done and things that need like 15 LOC in normal OpenCV can take 2 or 3 LOC. Unfortunately, some very low level task with pointers can't be made that easy. The licensing is only 400$ for a commercial application which is close to nothing if you are planning to sell your stuff. If it's for anything else, it's free. I would highly suggest EmguCV for anyone used to .NET and who want to use the power of OpenCV without the headache of C or C++. I agree that an automatic wrapper would be great, but even if it's done, wrapper like EmguCV will still have their place because the Library is written for .NET coders.
@Jean-Francois Thanks a lot for your comment. I agree with you, I developed more than one year ago my master thesis using Emgu (and some youtube tutorials) and it's the best wrapper for .NET developers. I see only some potential issues: 1) only one developer 2) Being an hand made wrapper this can introduce another layer of bugs 3) it's not always up to date with opencv, especially lately with new opencv development cycle
Yeah, EmguCV definitly need new blood in the development process but right now the current version is very stable and I know he's working on a new version.
I'm planning to release an updated C# interface to OpenCV 2.4.6 through NuGet over the next couple of days. These bindings were developed over the course of a year and include many features that I've missed from other attempts, namely:
I was very surprised by the decision to drop the C API, since it is still the easiest way for interoping with many high-level languages. I guess I could move my wrapper to use C++/CLI to get over this but I would then be limited to Windows-only support.
I'm very interested to follow up on efforts to do automatic generation of the C-interface. In fact, I may be even interested to contribute to it actively and push for an official C# wrapper built on top of it, if someone points me to how this was done for the other language bindings.
I was planning on doing this for my own C# interface anyway but if no one is currently working on it, I'm happy to hand you over the results.
I'll post here when I pre-release the CTP in NuGet if anyone wants to give it a try and help with the bug-hunt (although the unit test code base is growing). I'm versioning the bindings independently of OpenCV for now since the code was hand-written and it may be subject to independent changes. First pre-release will most likely be 2.5-ctp.
UPDATE: Just pushed a prerelease version of the wrapper on NuGet. Feel free to give it a try, will write a proper post when it's further along in testing.
Great news from you !!!! Maybe the best thing for the whole community would be to join your effort into pull request for C# automatic wrapper https://github.com/Itseez/opencv/pull/604
See above. Ended up taking a bit longer than expected, but here it is. I agree that an automatic C# wrapper would be ideal, although it's hard to automatize some of the design decisions that will really give it the .NET flavor. An automatic C interface generator would be a great first step, though.
I take a look at your wrapper and made a simple toy example with it and it works fine. The additional benefit of your wrapper and the only thing that seems more difficult to automate is GC management, other than that it seems possible to create a generator that produce an output similar to yours.
Right now you need to copy the DLLs to the project output folder yourself so that the wrapper will run. That should be about it. I'm actually working right now on making a NuGet package that will even do this for you. Hopefully it will be up soon (stay tuned).
Just want to say, I used the interface in a commercial kinect based application, it was pretty painless super light weight awesome license and easy to use. (the wrapper plus the opencv dll's increased the final msi by only ~3 mbs, major win:) The code was compact well written and easy to grok which meant if in the future I found a feature was missing I would be able to fix it and further contribute to the project. I looked at emguCV, cvsharp etc and they all looked a bit bloated had less friendly licenses and more importantly did not just work the first time I wacked them into my project.
Asked: 2013-08-14 10:05:48 -0600
Seen: 7,553 times
Last updated: Sep 02 '13
