Fix some typos in doc.
This commit is contained in:
parent
039f3d01a0
commit
1cdd8510fd
2
3rdparty/openvx/README.md
vendored
2
3rdparty/openvx/README.md
vendored
@ -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.
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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 ###
|
||||
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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
|
||||
|
||||
Loading…
Reference in New Issue
Block a user