Definitely on our todo list.
We will likely use boost.python for the bindings
We need to think a bit more about how to make this as flexible as possible, especially given the videomapping business and the need for a USB camera to announce its supported video modes when it is first connected to the host computer. Ideally, there should be only one C++ wrapper module that gets the input and output frames and then just forwards them to some process() function written in python. To avoid having to make a new wrapper for each new python module, we will likely proceed as follows:
- create a fake Vendor name, e.g., JeVoisPython. Then add the convention that when vendor is JeVoisPython, then the C++-to-python wrapper module should be loaded, and the Module name in the videomapping should then be interpreted as a python module name to be loaded into the wrapper.
- because the InputFrame and OutputFrame access wrappers are very important under tight timing (so we only request a frame when we absolutely need it, and we recycle it as soon as we are done with it), we will likely wrap those. Then we will wrap our conversion functions from RawImage (which is obtained out of InputFrame and OutputFrame) to OpenCV. Then users implement their image processing using Python bindings to OpenCV.
@pelrun - yes, compiling OpenCV with python is a first step, but I would not worry too much about the SDK for now, if we can get it working in host mode, we can help you with porting that to platform mode.