Typescript definitions

[johncant]

Hi,

Just wanted to let you know that I'm working on Typescript definitions for this OpenCV module. It would really benefit from your input when part of it is complete. I'm starting with the matrix class. I think I might have noticed some bugs in this repo, or just differences in APIs - I'll verify them and keep you posted. Maybe we can solve some of the issues as a result.

Here's my work in progress test (It just has to compile): https://github.com/johncant/DefinitelyTyped/blob/opencv/opencv/opencv-tests.d.ts

I've been littering a branch of the node-opencv code with TODOs as I go. Please think of it as a brain dump rather than a critique. :) https://github.com/johncant/node-opencv/commit/0088227b0f0dc819613af2569eefda6b6be282e2

[jamesmoey]

+1 nice

[johncant]

Well, I kind of paused my effort and started looking at generating typescript and new node bindings from the OpenCV code, using the Python bindings as a base. When I have something worth committing in OpenCV, I'll reference it here.

[peterbraden]

@Queuecumber is also working on generating bindings, perhaps you can collaborate with him?

[johncant]

Great! I'll post my efforts so far in the generated bindings thread

[Queuecumber]

@johncant We can definitely use the help but I'd encourage you to wait probably a couple of weeks for me to finish up the proof of concept which should provide us with a solid foundation for generating a full set of bindings.

As far as typescript is concerned, I think your efforts would be better spent making sure that our library (or rather the generated bindings we will produce) will be loadable from typescript rather than reimplementing the whole thing as that strikes me as a massive duplication of effort.

[johncant]

Hi @Queuecumber , would you like to post your WIP?

Typescript works by supplying a file that declares the types of each object and function call. It can import any valid node module, so no reimplementation or modification required. However, opencv is huge, and node-opencv deviates quite a lot from the original opencv API. IMO it would be far easier to autogenerate another javascript API and simultaneously generate typescript definitions than it would to manually write typescript definitions and keep them maintained. Most of the code to do this is even already present in OpenCV in the form of Python, Java and MATLAB bindings.

[Queuecumber]

I agree that auto-generating the typescript definitions along with the node bindings is the correct path, I'll leave that part to you since you are our resident expert on typescript

Don't worry too much about the current state of the node-opencv api, the generated bindings should match the original opencv implementation almost exactly (similar to the way that the python bindings do)

You can find my PoC at https://gitlab.com/Queuecumber/OCVNodeModulePOC when that is functional it will become a branch of this repository until we have a stable version. I have studied the python bindings and I am taking a slightly different (no python, only nodejs/c++) approach. The basic idea is to parse the source files using libclang and produce a set of javascript objects that describe them in a very basic way (only containing exactly what we need for generating bindings rather than the full AST that libclang can return). Then these descriptions are combined with a templating library to produce nodejs module source that can be compiled against opencv. The eventual goal is that people should not have to re-generate the bindings when they do an npm install, rather the bindings can be generated on a nightly basis and only those generated bindings will can be downloaded (of course people are free to generate the bindings themselves should they choose to) with saves people using the bindings the dependency on libclang.

[johncant]

Your repo looks really good! I can't get it to work yet though - src/pluggableDescriber.{cpp,hpp} is missing. I've taken a few more steps down the opencv/python route and am surprised at how fun and easy it is. It's looking like I might have some time over the next few weeks and would love to take steps down one of these two paths towards automatically generated bindings, whether it's helping you get your PoC working or generating bindings in the opencv repo. I've been thinking about what the right approach might be, but I don't want to drain your time by bombarding you with questions.

[Queuecumber]

Yeah the code is currently not building as a I am refactoring a lot

Feel free to bombard with questions. Eventually it would be nice to have these bindings provided by opencv but for now I think we can do it on our own since this has become the de facto source for opencv in javascript

[johncant]

My bindings are on hold for a while for various reasons, but even if I do continue with them, I'm happy to come back and add typescript definitions to your bindings. I actually prefer the idea of building bindings on npm install from a node module outside of opencv because it allows you to roll back to OpenCV versions before the JS bindings were generated. How are you going to find the OpenCV source code during npm install?

[peterbraden]

I think building the definitions from the source in install is infeasible precisely because we don't have the opencv source.

In terms of OpenCV support, the bindings should always support a reasonable range of OpenCV versions - the generation step can also emit version toggles etc.

[Queuecumber]

I agree with @peterbraden, we can't assume or force people to have the full opencv source code in order to use the library, though the option should be available to them if they choose. There should be some way to make sure the bindings are normalized for different library versions.

[johncant]

Yes it makes sense. Maybe we rig up a build server to generate the c++ for the bindings for every combination of opencv version and node-opencv-generated version, then download and compile them on npm install?

[Queuecumber]

I think so, for the first versions at least, to keep things simple. Eventually though it would be nice if the generated bindings could use some sort of pre-processor magic to turn on and off parts based on which opencv version it detects the user to have.

[johncant]

That's entirely feasible, just parse the output of pkg-config --libs opencv . Actually, I realised just now that you don't strictly need to have the full source code, only the headers, the location of which can be found using pkg-config --cflags opencv, so you could build the bindings on the user's machine. Will that work with libclang, or does it require the source code?

[Queuecumber]

It should be able to parse the headers just as well, so I think that is the best solution. We can either provide prebuilt bindings for your platform, let you build the bindings yourself, or let you generate and build your own bindings. For the initial version I want to keep it as simple as possible though

[jack-guy]

Any headway on this project? :)

[osdiab]

Ping on this project!

[Bellian]

Cant find any bindings on DefinitelyTyped. Anything new?

[brianhumphreys]

guys? :(

[peterbraden]

Patches are welcome...