`PyObject*` to `std::vector<T>` conversion logic:
- If user passed Numpy Array
- If array is planar and T is a primitive type (doesn't require
constructor call) that matches with the element type of array, then
copy element one by one with the respect of the step between array
elements. If compiler is lucky (or brave enough) copy loop can be
vectorized.
For classes that require constructor calls this path is not
possible, because we can't begin an object lifetime without hacks.
- Otherwise fall-back to general case
- Otherwise - execute the general case:
If PyObject* corresponds to Sequence protocol - iterate over the
sequence elements and invoke the appropriate `pyopencv_to` function.
`std::vector<T>` to `PyObject*` conversion logic:
- If `std::vector<T>` is empty - return empty tuple.
- If `T` has a corresponding `Mat` `DataType` than return
Numpy array instance of the matching `dtype` e.g.
`std::vector<cv::Rect>` is returned as `np.ndarray` of shape `Nx4` and
`dtype=int`.
This branch helps to optimize further evaluations in user code.
- Otherwise - execute the general case:
Construct a tuple of length N = `std::vector::size` and insert
elements one by one.
Unnecessary functions were removed and code was rearranged to allow
compiler select the appropriate conversion function specialization.
G-API: Wrap render functionality to python
* Wrap render Rect prim
* Add all primitives and tests
* Cover mosaic and image
* Handle error in pyopencv_to(Prim)
* Move Mosaic and Rect ctors wrappers to shadow file
* Use GAPI_PROP_RW
* Fix indent
this corrects bug #16592 where a Stream is created at
each GpuMat::load(arr,stream) call
a correct solution would have been to add a default to GpuMat::load
but due to circular dependence between Stream and GpuMat, this is not possible
add test_cuda_upload_download_stream to test_cuda.py
[G-API] Introduce cv.gin/cv.descr_of for python
* Implement cv.gin/cv.descr_of
* Fix macos build
* Fix gcomputation tests
* Add test
* Add using to a void exceeded length for windows build
* Add using to a void exceeded length for windows build
* Fix comments to review
* Fix comments to review
* Update from latest master
* Avoid graph compilation to obtain in/out info
* Fix indentation
* Fix comments to review
* Avoid using default in switches
* Post output meta for giebackend
[G-API] Introduce GOpaque and GArray for python
* Introduce GOpaque and GArray for python
* Fix ctor
* Avoid code duplication by using macros
* gapi: move Python-specific files to misc/python
* Fix windows build
Co-authored-by: Alexander Alekhin <alexander.a.alekhin@gmail.com>
they might be thrown from third-party code (notably Ogre in the ovis
module).
While Linux is kind enough to print them, they cause instant termination
on Windows.
Arguably, they do not origin from OpenCV itself, but still this helps
understanding what went wrong when calling an OpenCV function.
