potok/opencv
1
0
Fork 0
mirror of https://github.com/opencv/opencv.git synced 2026-07-31 00:03:03 +04:00
Code Packages Releases Wiki Activity

spelling fixes

Browse Source
This commit is contained in:
klemens
2019-02-09 22:29:54 +01:00
parent f414c16c13
commit 997b7b18af
36 changed files with 50 additions and 50 deletions
Download Patch File Download Diff File Expand all files Collapse all files
doc/pattern_tools/gen_pattern.py
+1 -1
View File
@@ -12,7 +12,7 @@ python gen_pattern.py -o out.svg -r 11 -c 8 -T circles -s 20.0 -R 5.0 -u mm -w 2
-u, --units - mm, inches, px, m (default mm)
-w, --page_width - page width in units (default 216)
-h, --page_height - page height in units (default 279)
-a, --page_size - page size (default A4), supercedes -h -w arguments
-a, --page_size - page size (default A4), supersedes -h -w arguments
-H, --help - show help
"""
doc/py_tutorials/py_bindings/py_bindings_basics/py_bindings_basics.markdown
+1 -1
View File
@@ -176,7 +176,7 @@ public:
// You would need to provide the method body in the binder code
CV_WRAP_PHANTOM(static void* context());
//! The wrapped method become equvalent to `get(int flags = ACCESS_RW)`
//! The wrapped method become equivalent to `get(int flags = ACCESS_RW)`
CV_WRAP_AS(get) Mat getMat(int flags CV_WRAP_DEFAULT(ACCESS_RW)) const;
};
@endcode
doc/py_tutorials/py_feature2d/py_brief/py_brief.markdown
+1 -1
View File
@@ -12,7 +12,7 @@ Theory
We know SIFT uses 128-dim vector for descriptors. Since it is using floating point numbers, it takes
basically 512 bytes. Similarly SURF also takes minimum of 256 bytes (for 64-dim). Creating such a
vector for thousands of features takes a lot of memory which are not feasible for resouce-constraint
vector for thousands of features takes a lot of memory which are not feasible for resource-constraint
applications especially for embedded systems. Larger the memory, longer the time it takes for
matching.
doc/tutorials/gapi/anisotropic_segmentation/porting_anisotropic_segmentation.markdown
+1 -1
View File
@@ -262,7 +262,7 @@ Fluid backend to make our graph cache-efficient on CPU.
G-API defines _backend_ as the lower-level entity which knows how to
run kernels. Backends may have (and, in fact, do have) different
_Kernel APIs_ which are used to program and integrate kernels for that
backends. In this context, _kernel_ is an implementaion of an
backends. In this context, _kernel_ is an implementation of an
_operation_, which is defined on the top API level (see
G_TYPED_KERNEL() macro).