From 1cdd8510fd9d3957df4fa513a1fbc2df32bf0346 Mon Sep 17 00:00:00 2001 From: Yulv-git Date: Sat, 30 Apr 2022 13:29:25 +0800 Subject: [PATCH] Fix some typos in doc. --- 3rdparty/openvx/README.md | 2 +- .../js_morphological_ops/js_morphological_ops.markdown | 2 +- doc/js_tutorials/js_setup/js_nodejs/js_nodejs.markdown | 2 +- .../py_feature_homography/py_feature_homography.markdown | 4 ++-- .../py_morphological_ops/py_morphological_ops.markdown | 2 +- .../imgproc/morph_lines_detection/morph_lines_detection.md | 2 +- 6 files changed, 7 insertions(+), 7 deletions(-) diff --git a/3rdparty/openvx/README.md b/3rdparty/openvx/README.md index 2f869a42bf..339b5072cc 100644 --- a/3rdparty/openvx/README.md +++ b/3rdparty/openvx/README.md @@ -77,7 +77,7 @@ E.g. external ref-counting is implemented for 1.0 version and native OpenVX one Also there are some **C++ 11** features are used (e.g. rvalue ref-s) when their availability is detected at ***compile time***. -C++ exceptions are used for errors indication instead of return codes. There are two types of exceptions are defined: `RuntimeError` is thrown when OpenVX C call returned unsuccessful result and `WrapperError` is thrown when a problem is occured in the wrappers code. Both exception calsses are derived from `std::exception` (actually from its inheritants). +C++ exceptions are used for errors indication instead of return codes. There are two types of exceptions are defined: `RuntimeError` is thrown when OpenVX C call returned unsuccessful result and `WrapperError` is thrown when a problem is occurred in the wrappers code. Both exception calsses are derived from `std::exception` (actually from its inheritants). The so called **OpenVX objects** (e.g. `vx_image`) are represented as C++ classes in wrappers. All these classes use automatic ref-counting that allows development of exception-safe code. diff --git a/doc/js_tutorials/js_imgproc/js_morphological_ops/js_morphological_ops.markdown b/doc/js_tutorials/js_imgproc/js_morphological_ops/js_morphological_ops.markdown index b5e10e0e67..9ffa218bb2 100644 --- a/doc/js_tutorials/js_imgproc/js_morphological_ops/js_morphological_ops.markdown +++ b/doc/js_tutorials/js_imgproc/js_morphological_ops/js_morphological_ops.markdown @@ -52,7 +52,7 @@ Try it ### 2. Dilation -It is just opposite of erosion. Here, a pixel element is '1' if atleast one pixel under the kernel +It is just opposite of erosion. Here, a pixel element is '1' if at least one pixel under the kernel is '1'. So it increases the white region in the image or size of foreground object increases. Normally, in cases like noise removal, erosion is followed by dilation. Because, erosion removes white noises, but it also shrinks our object. So we dilate it. Since noise is gone, they won't come diff --git a/doc/js_tutorials/js_setup/js_nodejs/js_nodejs.markdown b/doc/js_tutorials/js_setup/js_nodejs/js_nodejs.markdown index 2fe17c5db6..17ced36b5a 100644 --- a/doc/js_tutorials/js_setup/js_nodejs/js_nodejs.markdown +++ b/doc/js_tutorials/js_setup/js_nodejs/js_nodejs.markdown @@ -223,7 +223,7 @@ Before the example, is worth consider first how files are handled in emscripten These C++ sources use standard APIs to access the filesystem and the implementation often ends up in system calls that read a file in the hard drive. Since JavaScript applications in the browser don't have access to the local filesystem, [emscripten emulates a standard filesystem](https://emscripten.org/docs/api_reference/Filesystem-API.html) so compiled C++ code works out of the box. -In the browser, this filesystem is emulated in memory while in Node.js there's also the possibility of using the local filesystem directly. This is often preferable since there's no need of copy file's content in memory. This section is explains how to do do just that, this is, configuring emscripten so files are accessed directly from our local filesystem and relative paths match files relative to the current local directory as expected. +In the browser, this filesystem is emulated in memory while in Node.js there's also the possibility of using the local filesystem directly. This is often preferable since there's no need of copy file's content in memory. This section explains how to do just that, this is, configuring emscripten so files are accessed directly from our local filesystem and relative paths match files relative to the current local directory as expected. ### The example ### diff --git a/doc/py_tutorials/py_feature2d/py_feature_homography/py_feature_homography.markdown b/doc/py_tutorials/py_feature2d/py_feature_homography/py_feature_homography.markdown index f8836b095b..6abac2c57b 100644 --- a/doc/py_tutorials/py_feature2d/py_feature_homography/py_feature_homography.markdown +++ b/doc/py_tutorials/py_feature2d/py_feature_homography/py_feature_homography.markdown @@ -18,7 +18,7 @@ is sufficient to find the object exactly on the trainImage. For that, we can use a function from calib3d module, ie **cv.findHomography()**. If we pass the set of points from both the images, it will find the perspective transformation of that object. Then we -can use **cv.perspectiveTransform()** to find the object. It needs atleast four correct points to +can use **cv.perspectiveTransform()** to find the object. It needs at least four correct points to find the transformation. We have seen that there can be some possible errors while matching which may affect the result. To @@ -64,7 +64,7 @@ for m,n in matches: if m.distance < 0.7*n.distance: good.append(m) @endcode -Now we set a condition that atleast 10 matches (defined by MIN_MATCH_COUNT) are to be there to +Now we set a condition that at least 10 matches (defined by MIN_MATCH_COUNT) are to be there to find the object. Otherwise simply show a message saying not enough matches are present. If enough matches are found, we extract the locations of matched keypoints in both the images. They diff --git a/doc/py_tutorials/py_imgproc/py_morphological_ops/py_morphological_ops.markdown b/doc/py_tutorials/py_imgproc/py_morphological_ops/py_morphological_ops.markdown index 35e716d8e9..84a62d14cd 100644 --- a/doc/py_tutorials/py_imgproc/py_morphological_ops/py_morphological_ops.markdown +++ b/doc/py_tutorials/py_imgproc/py_morphological_ops/py_morphological_ops.markdown @@ -48,7 +48,7 @@ Result: ### 2. Dilation -It is just opposite of erosion. Here, a pixel element is '1' if atleast one pixel under the kernel +It is just opposite of erosion. Here, a pixel element is '1' if at least one pixel under the kernel is '1'. So it increases the white region in the image or size of foreground object increases. Normally, in cases like noise removal, erosion is followed by dilation. Because, erosion removes white noises, but it also shrinks our object. So we dilate it. Since noise is gone, they won't come diff --git a/doc/tutorials/imgproc/morph_lines_detection/morph_lines_detection.md b/doc/tutorials/imgproc/morph_lines_detection/morph_lines_detection.md index ccce36270c..39a76a74ce 100644 --- a/doc/tutorials/imgproc/morph_lines_detection/morph_lines_detection.md +++ b/doc/tutorials/imgproc/morph_lines_detection/morph_lines_detection.md @@ -123,7 +123,7 @@ Get image from [here](https://raw.githubusercontent.com/opencv/opencv/3.4/doc/tu #### Output images -Now we are ready to apply morphological operations in order to extract the horizontal and vertical lines and as a consequence to separate the the music notes from the music sheet, but first let's initialize the output images that we will use for that reason: +Now we are ready to apply morphological operations in order to extract the horizontal and vertical lines and as a consequence to separate the music notes from the music sheet, but first let's initialize the output images that we will use for that reason: @add_toggle_cpp @snippet samples/cpp/tutorial_code/ImgProc/morph_lines_detection/Morphology_3.cpp init