Discussion on exposing the C++ API

[cassandracomar]

I've been using this library on and off for the last year and a half or so, and sadly never contributed anything back. I'm hoping to change that now.

For the longest time, I've been wanting access to the C++ portions of the OpenCV API, and never done more than create a couple wrappers to make them available within my own (toy) applications. The reason is quite simple -- C++ <--> Haskell is an open and difficult problem. The easiest approach is incredibly tedious and error prone, and better solutions have never really manifested. I'm going to try and tackle this problem.

I see two major approaches to this problem from the research I've been doing. The first is to take on the difficult task of creating a C API that wraps the portions of the C++ API we need. If I did this, I'd probably do it as its own library so that other people/languages could make use of that API. The upsides to this approach are the lack of extra dependencies, and it's relatively fast compared to the other approaches I'm considering. The downsides are that this is strictly unsupported by the OpenCV community (after all, they elected to move away from C, and have basically stopped supporting it), and as a result, this approach is brittle and will require potentially major revisions with every update to OpenCV.

The other approach is to use something like MissingPy to instead expose the Python API. The upside here is that the data structures map more nicely into Haskell and the Python API already exists -- there's no need to create an entirely new API, we can just map to the one provided to us. The downside is of course that those API calls have to be routed through a Python interpreter, and are therefore inherently slower.

So what do the people who actually use/develop CV think? I'm very torn on the issue and am willing to take it in either direction.

Also, what portions of the API would be most useful to you? Personally I'd like to be able to use the feature detectors/descriptors, the machine learning libraries, and the OpenCL module, so those are the features I'll work on first.

EDIT: And if this is the wrong way to have this discussion, feel free to close this and direct me to a more appropriate venue.

[aleator]

Having the whole C++ API to be accessible is something I'd give money for.

Not having it is the main thing why CV is notreally progressing currently (besides me pretty much changing my field of study).

The options, in short, are not so good:

1. Create a C api: Huge amount of work. Very tedious to maintain. If this would be to happen, we'd probably need help. There might be other people who would benefit from this which would make this strategy viable (if we could recruit them).
2. Do something similar than language-c-inline. Unfortunately,
   c++ is hell to parse.

2b. There is also cgen, which seems somewhat successful. Perhaps we could, beg/steal/borrow/contribute?

1. MissingPy. That's clever actually. It smells a bit over complex however.

Ideally, what we would like is to have the lowest level interface (something that we currently use bindings-dsl for) to cover whole of opecv and have some kind of strategy for getting new opencv versions supported.

Anyways, if you are willing to take lead, we'll help as much as we have time for.

[cassandracomar]

Huh, for some reason Github never notified me that you responded to this. I figured this comment went ignored, and so this project went on the back burner for a while. I'm currently investigating fficxx which is similar to cgen but seems to actually be under active development. I'll give both a shot and see which one works better. I'll probably post again this weekend with some preliminary results.