I haven't seen this in any issued tagged "python bindings", so I'll give it a go...
The "pythonic" thing to do would be accepting lists/tuples where arrays are expected, and accepting lists/arrays where tuples are expected.
In one instance, an error message asking for an UMat (when the API wants a numpy array) has just confused a newbie in the IRC channel:
>>> contour = [[0,0], [10,0], [10,10], [0,10]]
>>> cv.pointPolygonTest(np.array(contour), (5,5), True)
5.0
>>> cv.pointPolygonTest(contour, (5,5), True)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: Expected cv::UMat for argument 'contour'
Another slight impedance mismatch I see sometimes is the new style getargs format but argument is not a tuple error message when the bindings expect a tuple, to be converted into a cv::Size or similar C++ API type. That too could be made more accomodating.
I have no idea how OpenCV generates its python bindings. It used to be some custom code generation. Maybe someone would like to take a shot at it. With some discussion and pointers, this might even become suitable to work on for beginners?
I haven't seen this in any issued tagged "python bindings", so I'll give it a go...
The "pythonic" thing to do would be accepting lists/tuples where arrays are expected, and accepting lists/arrays where tuples are expected.
In one instance, an error message asking for an
UMat(when the API wants a numpy array) has just confused a newbie in the IRC channel:Another slight impedance mismatch I see sometimes is the
new style getargs format but argument is not a tupleerror message when the bindings expect a tuple, to be converted into acv::Sizeor similar C++ API type. That too could be made more accomodating.I have no idea how OpenCV generates its python bindings. It used to be some custom code generation. Maybe someone would like to take a shot at it. With some discussion and pointers, this might even become suitable to work on for beginners?