Mono / .NET bindings

[azeno]

hi, using IKVM (http://www.ikvm.net/) i've created bindings for Mono / .NET using the existing java bindings. in order to get them built, IKVM needs to be in the system's PATH environment variable.

i modified the java for desktop bindings a little so they do the System.loadLibrary call on their own. doing it the same way as in the java examples (letting the user call it) doesn't work in .NET due to different class loading behaviour.

i'm fairly new to CMake, so any hints/help in that direction are appreciated - for example i've no clue what'd be the proper way to copy native dependencies (ikvm-native-win32) based on the current target platform (x86/x64). i'd like to see an output folder like this: mono/opencv-mono.dll -- the mono bindings mono/IKVM.*.dll -- managed assemblies needed by opencv-mono.dll mono/x86/opencv_java249.dll -- native dependency needed by opencv-mono.dll mono/x86/ikvm-native-win32-x86.dll -- native dependency needed by IKVM.Runtime.JNI.dll mono/x64/...

i've not yet written any tests yet. simply tried some basic examples which worked just fine. wanted to sort out above mentioned build issues first.

thanks, elias

[vpisarev]

if OpenCV Java bindings can be transformed C# in such a simple way - that's really cool!!!

a few questions/suggestions/requests:

1. We usually name modules with the bindings by the language name: java, python ... Shouldn't mono (which is name of the alternative, not the "official" implementation of C# and .NET) be renamed to csharp then?
2. Is it possible to add at least a single sample into opencv/samples/csharp that would demonstrate the use of the bindings?
3. How are the bindings packaged? On Java we have .jar's, what's the representation of the C# bindings?
4. It would be really nice to have some short description - how-to guide on the bindings usage. It can be done differently. This is a nice example of such guide for Java: http://docs.opencv.org/trunk/doc/tutorials/introduction/desktop_java/java_dev_intro.html. I'm not asking you to write such complete document, but if you at least make some stub text-only description - maybe slightly extended version of what you've already put above, that would be really useful!

thanks again for your contribution!

[vpisarev]

it looks like the patch breaks compilation of the java bindings. See http://pullrequest.opencv.org. The page is updated automatically after your further commits to the branch (though, give our buildbot some time to catch up with your changes)

[kirill-korniakov]

Wow! Vadim, AFAIU, the idea is to run the same Java code on .NET, since .NET is a multi-language platform. That means that we shouldn't rename it to csharp, but I agree that mono is probably not the best name. Another concern, that manually written bindings to the C# may be more performant. And this task is not addressed here if I'm not mistaken. But in any case, current proposal is quite useful and interesting!

Elias, thank you for the code! I agree with Vadim, that a sample and a draft manual/tutorial/readme would help a lot. It is not clear how to reproduce your results, and what should be done next.

[azeno]

@vpisarev ad 1) C# is just one of many .net languages which can make use of those bindings. .NET / mono assemblies (dll file, similar to a jar file in java) contain CIL (common intermediate language) code. .NET is windows only, mono runs on much more platforms that's why i thought it would be a better option. ad 2) yes, i'll do that. ad 3) opencv-mono.dll - similiar as the opencv-java249.jar it depends on the native libraries and in addition a few ikvm assemblies. see my intial post. would be nice if someone could give me some hints regarding cmake. ad 4) will do that too.

[vpisarev]

ok. I see

[azeno]

i've added a little example. one might need to adjust the reference paths though. is there some kind of guideline how to setup example projects which need to reference the opencv binaries?

regarding performance: it's the first time i try such a thing with ikvm, so i can't really say how well it performs when dealing with calls to native code. i'll report back on that issue in a couple of days once i've collected some results.

[kirill-korniakov]

What I mean is that in Java wrappers we have to make expensive JNI calls every time we do a native call. So, for example, if you have a loop where you access individual pixels, it will take too much time. And we heard that C# is much more efficient when dealing with calls to native libraries. Thus we thought that it is possible to create custom wrappers, that will use this strenght of C#. But this wasn't investigated further.

IKVM, if I understand correctly, will go through the same JNI path. This is acceptable, performance should be close to what we have in Java. User shouldn't work with individual pixels, and if he really needs to do a hundred of native calls per frame, these calls should be packed into a single method with manually written Java wrapper.

[Daniil-Osokin]

@apavlenko @azeno Any updates here?

[apavlenko]

I think we'll take this but with some minor changes.

[vinograd47]

@azeno Any updates here?

[azeno]

sorry not yet. will probably have some time this weekend.

[apavlenko]

@azeno do you mind if I take your changes, make my improvements and make another pull request or even split it into two ones?

[azeno]

sure go ahead.

[AnnaPetrovicheva]

Andrey, any news on this pull request?

[apavlenko]

Plan work with it on this week.

[alekcac]

Andrey, any updates?

[tomoprime]

Hi I'm fairly new to cmake on a Mac and wanted to test out your Mono / .NET bindings for opencv. Is there any required libs I need? I grabbed cmake with macports. I would like to create a private binding any tips would be appreciated.

Should I simple build with: mkdir mytestbuild cd mytestbuild cmake ../opencv-your-mono-.net-source make

[azeno]

@tomoprime : as i explained in my initial post, IKVM must be in your PATH environment variable. after that follow the official build instructions. you should see mono as one of the OpenCV modules to be built.

[tomoprime]

Yeah I think already have ikvm...

Toms-MacBook-Air:~ Tomo$ ikvm IKVM.NET Launcher version 0.46.0.1 Copyright (C) 2002-2011 Jeroen Frijters http://www.ikvm.net/

usage: ikvm [-options] [args...](to execute a class) or ikvm -jar [-options] [args...](to execute a jar file)

[tomoprime]

The last I had checked my mytestbuild/modules/mono folder was empty.

[azeno]

and you checked out this pull request with git? do you see the java bindings? these mono bindings depend on the java bindings. i must admit i only tested it under windows. so could be that there're issues when building with linux/mac...

[tomoprime]

yeah I see the java bindings ok. Would it be easier for me to use SWIG ? At least we could reuse the interfaces for other languages.

[snosov1]

@apavlenko Any updates, Andrey?

[alekcac]

@apavlenko Andrey, any ideas?

[mdim]

@apavlenko let me remind you about this..

[kirill-korniakov]

And can we put this to extra modules? All the necessary parts could be taken to main repository, but the mono folder can be put to opencv_contrib, so it is developed further.

@apavlenko, do you think we can do this?

[apavlenko]

Yes, I plan to put ikvm/mono bindings into the 'contrib' repo. I plan to close this PR right after I make a PR to contrib. But it's possible to close this PR earlier.

[BKNio]

@apavlenko any updates?

[elliotwoods]

/me cheers on @apavlenko any updates?

[smakhtin]

Yep, any updates? We need it )

[apavlenko]

Actually what I plan to do is to rebase the code to the current state and move it into a separate module in the https://github.com/Itseez/opencv_contrib repository. Still can't find enough free time for that... If anybody else is ready to do this before me - welcome to contribute!

[glopesdev]

Hey guys. People in the forums were mentioning I should post here my efforts to have a .NET interface to OpenCV, so here goes.

I started it before I knew of these efforts. It has a different approach, since the wrapper was hand-coded to target the latest C API. These bindings were developed over the course of a year and include many features that I've missed from other attempts, namely:

• Fully Mono compatible (only P/Invoke is used)
• Very close to 100% support of the latest C API (including undocumented functions)
• Full documentation/intellisense for all supported methods, classes and enum members (arduously mined from many different sources)
• Support for exceptions
• Garbage-collector friendly:
  • GC is aware of the actual memory used by matrices and images
  • Pointers are guaranteed to survive function calls even if concurrent garbage collection happens
• Object model following C++ API as much as possible (towards future increased support of C++ API)
• BSD-style license (MIT)

You can find the code base at: https://bitbucket.org/horizongir/opencv.net I've also published a NuGet package at: https://www.nuget.org/packages/OpenCV.Net/

The advantage of the NuGet is that it allows you to add the wrapper to your project and run it immediately since it also deploys the native libraries.

@apavlenko: Does your wrapper keep a dependency to IKVM? That would be a deal-breaker for my particular scenario. Otherwise, it sounds great.

I agree for the long term it's best to automatically generate these wrappers. Someone also mentioned here that there were plans to automatically generate the C interface starting from 3.0 onwards.

I find that a great idea! C has the best possible interop with other high-level languages and is also the ideal basis for the C# wrapper as P/Invoke is still the most efficient and cross-platform friendly technique available to interop .NET with native.

[AnnaPetrovicheva]

@apavlenko We really need your expertise here!

[BKNio]

@apavlenko please review

[Daniil-Osokin]

Hi @azeno, @smakhtin, @elliotwoods. Let's cope with this request! Please, rebase the code to the current state and move it into a separate module in the https://github.com/Itseez/opencv_contrib repository. You see, it's been a long time since initial request, so, please, help OpenCV to be C# compatible! Who will finish this?

[smakhtin]

@Daniil-Osokin Maybe i can do this. But last time i checked this commits, i can't successfully compile this bindings. Can anyone provide me a better instructions about building process and contributing to opencv extra modules?

[Daniil-Osokin]

@smakhtin Vadim, thanks for response! Contributing to https://github.com/Itseez/opencv_contrib is basically creating there folder in modules directory (mono in this PR) and adding appropriate CMakeLists.txt for it (modules/mono/CMakeLists.txt in this PR) + sample should go to contrib repository. So, this PR should be splitted into two: one with defined module in contrib, other changes to main repo. But, looks like, first of all we need an instruction how to make it work. @azeno Elias, could you help us?

[azeno]

i'll try. i hope to have some spare time at the end of this week.

[Daniil-Osokin]

Great, thanks!

[azeno]

i had a look at it at the weekend and by pulling in the latest changes of upstream i got a couple of merge conflicts which i didn't resolve yet as i was giving the whole thing of creating bindings for c# another try with the now fairly major https://github.com/mono/CppSharp project. my first attempt looks promising but i still have to figure out a couple of issues, mainly about mapping the std::* classes - see my question here: https://github.com/mono/CppSharp/issues/221

so i'll wait for an answer there and if it doesn't lead to anything i'll try to finish this approach.

[Daniil-Osokin]

Hi Elias, thanks, lets wait for answer.

[vpisarev]

@azeno, sorry for long delay. I suggest to put this functionality to github.com/itseez/opencv_contrib and develop it further there; if you want, you can become the module maintainer and put the updates to contrib without asking us. What do you think?

[azeno]

I've already forked the opencv_contrib repository in order to get a new pull request out. You can have a glimpse at it here: https://github.com/azeno/opencv_contrib/tree/master/modules/dotnet - I've a more up-to-date version on a different computer, didn't push it yet. Anyway what's hindering the progress on the new pull request right now is twofold:

• I still have to push a couple of commits to CppSharp - I don't want to generate the bindings based on a forked version of the code generator.
• CMake and .NET are not especially friends - I found a way to get the generator and the actual language bindings project being generated with CMake on windows, but in a very unusal way with a couple of drawbacks, like the inability to properly debug in visual studio or generating the documentation file for the bindings. I've therefor decided to add another meta-build system called premake, which has proper support for .NET, but will still need to figure out how to get that integrated into CMake...

[glopesdev]

I've looked briefly at the generated bindings. They look like they are using C++/CLI. Is this correct? If that's the case then they will not work on other platforms/Mono...

Are you guys sure it's not easier/more general/convenient to just pre-generate a C wrapper DLL exposing all the C++ functionality and then wrapping that using regular P/Invoke?

[azeno]

CppSharp has two generator backends, one targeting C++/CLI and the other plain C#. The C++/CLI is windows only yes, though @tritao told me that there's some hope that C++/CLI will come to Mono this summer - see his answer here: https://github.com/mono/CppSharp/issues/221 Using the C# backend one could generate the bindings for windows/osx/linux, but it would probably need some hand written helper code like seen in the other opencv language bindings to get templated classes/functions to work. I wanted to see first how far I'd come with auto-generated code only - that's why I chose the C++/CLI backend for now. My hope is that the generated bindings will improve over time / be available on more platforms as CppSharp progresses - which I imagine could also be a third backend using a pre-generated C wrapper DLL like you proposed.

[glopesdev]

Nice, good to know :) As far as hand-written code goes, I'm happy to adapt my current wrapper OpenCV.NET, to work on top of the p/invoke generated bindings. There are many advantages to having a managed layer work on top of the bindings, which I've listed further up in these comments (https://github.com/Itseez/opencv/pull/604#issuecomment-29670423).

Maybe I'll create a fork to give this integration a go.

[vpisarev]

I think, since we now have opencv_contrib, let's close this PR and wait for the corresponding commit to opencv_contrib