- Make sure the files `aarcascade_frontalface_default.xml` and `haarcascade_eye.xml` are present in project's directory. They can be obtained from [OpenCV sources](https://github.com/opencv/opencv/tree/5.x/data/haarcascades).
- Make sure a sample image file `lena.jpg` exists in project's directory. It should display people's faces for this example to make sense. The following image is known to work:
The following command should generate the file `output3.jpg`:
The expected output in Linux terminal for `multiview_calibration_images` data (from `opencv_extra/testdata/python/` generated in Blender) should be the following:
@ -116,21 +116,21 @@ Firstly, the sample shows positions of cameras, checkerboard (of a random frame)
If images are not known, then a simple plot with arrows (from given point to the back-projected one) visualizing errors is shown. The color of arrows highlights the error values. Additionally, the title reports mean error on this frame, and its accuracy among other frames used in calibration.
The following test instances were synthetically generated (see `opencv/apps/python-calibration-generator/calibration_generator.py`):
This instance has large Gaussian points noise.
Another example, with more complex tree structure is here, it shows a weak connection between two groups of cameras.
If files to images are provided, then the output is an image with plotted arrows:
* a. To reduce the total number of parameters, all rotation and translation vectors estimated in the first step from intrinsics calibration with the lowest error are transformed to be relative with respect to the root camera.
* b. The total number of parameters is (NUM_CAMERAS - 1) x (3 + 3) + NUM_FRAMES x (3 + 3), where 3 stands for a rotation vector and 3 for a translation vector. The first part of parameters are extrinsics, and the second part is for rotation and translation vectors per frame.
* c. Robust function is additionally applied to mitigate impact of outlier points during the optimization. The function has the shape of derivative of Gaussian, or it is $x * exp(-x/s)$ (efficiently implemented by approximation of the `exp`), where `x` is a square pixel error, and `s` is manually pre-defined scale. The choice of this function is that it is increasing on the interval of `0` to `y` pixel error, and it’s decreasing thereafter. The idea is that the function slightly decreases errors until it reaches `y`, and if error is too high (more than `y`) then its robust value limits to `0`. The value of scale factor was found by exhaustive evaluation that forces robust function to almost linearly increase until the robust value of an error is 10 px and decrease afterwards (see graph of the function below). The value itself is equal to 30, but could be modified in OpenCV source code.
@ -22,7 +22,7 @@ In this tutorial, we first introduce how to obtain the custom OCR model, then ho
After completing the model training, please use [transform_to_onnx.py](https://github.com/zihaomu/deep-text-recognition-benchmark/blob/master/transform_to_onnx.py) to convert the model into onnx format.
#### Execute in webcam
### Execute in webcam
The Python version example code can be found at [here](https://github.com/opencv/opencv/blob/5.x/samples/dnn/text_detection.py).
Example:
@ -44,9 +44,10 @@ Their performance at different text recognition datasets is shown in the table b
The performance of the text recognition model were tesred on OpenCV DNN, and does not include the text detection model.
The performance of the text recognition model were tested on OpenCV DNN, and does not include the text detection model.
### Model selection suggestion
#### Model selection suggestion:
The input of text recognition model is the output of the text detection model, which causes the performance of text detection to greatly affect the performance of text recognition.
DenseNet_CTC has the smallest parameters and best FPS, and it is suitable for edge devices, which are very sensitive to the cost of calculation. If you have limited computing resources and want to achieve better accuracy, VGG_CTC is a good choice.
@ -112,7 +112,7 @@ Get image from [here](https://raw.githubusercontent.com/opencv/opencv/5.x/doc/tu
#### Grayscale to Binary image
### Grayscale to Binary image
@add_toggle_cpp
@snippet samples/cpp/tutorial_code/ImgProc/morph_lines_detection/Morphology_3.cpp bin
@ -128,7 +128,7 @@ Get image from [here](https://raw.githubusercontent.com/opencv/opencv/5.x/doc/tu
#### Output images
### 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 music notes from the music sheet, but first let's initialize the output images that we will use for that reason:
@ -144,7 +144,7 @@ Now we are ready to apply morphological operations in order to extract the horiz
As we specified in the theory in order to extract the object that we desire, we need to create the corresponding structure element. Since we want to extract the horizontal lines, a corresponding structure element for that purpose will have the following shape:
@ -182,7 +182,7 @@ and again this is represented as follows:
#### Refine edges / Result
### Refine edges / Result
As you can see we are almost there. However, at that point you will notice that the edges of the notes are a bit rough. For that reason we need to refine the edges in order to obtain a smoother result:
This document is a basic guide to building the OpenCV libraries with CUDA support for use in the Tegra environment. It covers the basic elements of building the version 3.1.0 libraries from source code for three (3) different types of platforms:
@ -36,7 +36,7 @@ The OpenCV build system supports native compilation for all the supported platfo
At the present time, this document focuses only on native compilation.
Getting the Source Code {#tutorial_building_tegra_cuda_getting_the_code}
=======================
-----------------------
There are two (2) ways to get the OpenCV source code:
@ -45,8 +45,7 @@ There are two (2) ways to get the OpenCV source code:
For this guide, the focus is on using the git repositories. This is because the 3.1.0 version of OpenCV will not build with CUDA 8.0 without applying a few small upstream changes from the git repository.
OpenCV
------
### OpenCV
Start with the `opencv` repository:
@ -93,8 +92,7 @@ You should see output similar to:
At this point, the `opencv` repository is ready for building.
OpenCV Extra
------------
### OpenCV Extra
The `opencv_extra` repository contains extra data for the OpenCV library, including the data files used by the tests and demos. It must be cloned separately:
@ -111,12 +109,11 @@ You may opt to not fetch this repository if you do not plan on running the tests
__Note:__ If you plan to run the tests, some tests expect the data to be present and will fail without it.
Preparation and Prerequisites {#tutorial_building_tegra_cuda_preparation}
=============================
-----------------------------
To build OpenCV, you need a directory to create the configuration and build the libraries. You also need a number of 3rd-party libraries upon which OpenCV depends.
Prerequisites for Ubuntu Linux
------------------------------
### Prerequisites for Ubuntu Linux
These are the basic requirements for building OpenCV for Tegra on Linux:
@ -186,8 +183,7 @@ The commands that will do this:
Once all the necessary packages are installed, you can configure the build.
Preparing the Build Area
------------------------
### Preparing the Build Area
Software projects that use the CMake system for configuring their builds expect the actual builds to be done outside of the source tree itself. For configuring and building OpenCV, create a directory called "build" in the same base directory into which you cloned the git repositories:
@ -197,7 +193,7 @@ Software projects that use the CMake system for configuring their builds expect
You are now ready to configure and build OpenCV.
Configuring OpenCV for Building {#tutorial_building_tegra_cuda_configuring}
===============================
-------------------------------
The CMake configuration options given below for the different platforms are targeted towards the functionality needed for Tegra. They are based on the original configuration options used for building OpenCV 2.4.13.
@ -209,8 +205,7 @@ For the Linux-based platforms, the shown value for the `CMAKE_INSTALL_PREFIX` pa
In each of the `cmake` invocations below, the last parameter, `OPENCV_TEST_DATA_PATH`, tells the build system where to find the test-data that is provided by the `opencv_extra` repository. When this is included, a `make install` installs this test-data alongside the libraries and example code, and a `make test` automatically provides this path to the tests that have to load data from it. If you did not clone the `opencv_extra` repository, do not include this parameter.
Vibrante V4L Configuration
--------------------------
### Vibrante V4L Configuration
Supported platform: Drive PX 2
@ -251,8 +246,7 @@ The configuration provided above builds the Python bindings for Python 2 (but no
-DBUILD_opencv_python2=OFF
Jetson L4T Configuration
------------------------
### Jetson L4T Configuration
Supported platforms:
@ -261,7 +255,7 @@ Supported platforms:
Configuration is slightly different for the Jetson TK1 and the Jetson TX1 systems.
### Jetson TK1
#### Jetson TK1
$ cmake \
-DCMAKE_BUILD_TYPE=Release \
@ -299,7 +293,7 @@ Configuration is slightly different for the Jetson TK1 and the Jetson TX1 system
__Note:__ This uses CUDA 6.5, not 8.0.
### Jetson TX1
#### Jetson TX1
$ cmake \
-DCMAKE_BUILD_TYPE=Release \
@ -336,8 +330,7 @@ __Note:__ This uses CUDA 6.5, not 8.0.
__Note:__ This configuration does not set the `ENABLE_NEON` parameter.
Ubuntu Desktop Linux Configuration
----------------------------------
### Ubuntu Desktop Linux Configuration
Supported platforms:
@ -383,12 +376,11 @@ This configuration is nearly identical to that for V4L and L4T, except that the
As with previous examples, the configuration given above builds the Python bindings for Python 2 (but not Python 3) as part of the build process.
Building OpenCV {#tutorial_building_tegra_cuda_building}
===============
---------------
Once `cmake` finishes configuring OpenCV, building is done using the standard `make` utility.
Building with `make`
--------------------
### Building with `make`
The only parameter that is needed for the invocation of `make` is the `-j` parameter for specifying how many parallel threads to use. This varies depending on the system and how much memory is available, other running processes, etc. The following table offers suggested values for this parameter:
@ -408,12 +400,11 @@ By default, CMake hides the details of the build steps. If you need to see more
Once the build completes successfully, you have the option of running the extensive set of tests that OpenCV provides. If you did not clone the `opencv_extra` repository and specify the path to `testdata` in the `cmake` invocation, then testing is not recommended.
Testing under Linux
-------------------
### Testing under Linux
To run the basic tests under Linux, execute:
@ -425,7 +416,7 @@ This executes `ctest` to carry out the tests, as specified in CTest syntax withi
In this example, there are two (2) arguments passed to `ctest`: `--verbose` and `--parallel 3`. The first argument causes the output from `ctest` to be more detailed, and the second causes `ctest` to run as many as three (3) tests in parallel. As with choosing a thread count for building, base any choice for testing on the available number of processor cores, physical memory, etc. Some of the tests do attempt to allocate significant amounts of memory.
### Known Issues with Tests
#### Known Issues with Tests
At present, not all of the tests in the OpenCV test suite pass. There are tests that fail whether or not CUDA is compiled, and there are tests that are only specific to CUDA that also do not currently pass.
@ -434,7 +425,7 @@ __Note:__ There are no tests that pass without CUDA but fail only when CUDA is i
As the full lists of failing tests vary based on platform, it is impractical to list them here.
Installing OpenCV is very straightforward. For the Linux-based platforms, the command is:
@ -443,14 +434,13 @@ Installing OpenCV is very straightforward. For the Linux-based platforms, the co
Depending on the chosen installation location, you may need root privilege to install.
Building OpenCV 2.4.X {#tutorial_building_tegra_cuda_opencv_24X}
=====================
---------------------
If you wish to build your own version of the 2.4 version of OpenCV, there are only a few adjustments that must be made. At the time of this writing, the latest version on the 2.4 tree is 2.4.13. These instructions may work for later versions of 2.4, though they have not been tested for any earlier versions.
__Note:__ The 2.4.X OpenCV source does not have the extra modules and code for Tegra that was upstreamed into the 3.X versions of OpenCV. This part of the guide is only for cases where you want to build a vanilla version of OpenCV 2.4.
Selecting the 2.4 Source
------------------------
### Selecting the 2.4 Source
First you must select the correct source branch or tag. If you want a specific version such as 2.4.13, you want to make a local branch based on the tag, as was done with the 3.1.0 tag above:
@ -466,14 +456,13 @@ If you simply want the newest code from the 2.4 line of OpenCV, there is a `2.4`
There is no need for the `git cherry-pick` commands used with 3.1.0 when building the 2.4.13 source.
Configuring
-----------
### Configuring
Configuring is done with CMake as before. The primary difference is that OpenCV 2.4 only provides Python bindings for Python 2, and thus does not distinguish between Python 2 and Python 3 in the CMake parameters. There is only one parameter, `BUILD_opencv_python`. In addition, there is a build-related parameter that controls features in 2.4 that are not in 3.1.0. This parameter is `BUILD_opencv_nonfree`.
Configuration still takes place in a separate directory that must be a sibling to the `opencv` and `opencv_extra` directories.
The following is a table of all the parameters passed to CMake in the recommended invocations above. Some of these are parameters from CMake itself, while most are specific to OpenCV.
OpenCV can change its behavior depending on the runtime environment:
- enable extra debugging output or performance tracing
@ -18,7 +18,7 @@ OpenCV can change its behavior depending on the runtime environment:
- ⭐ marks most popular variables
- variables with names like this `VAR_${NAME}` describes family of variables, where `${NAME}` should be changed to one of predefined values, e.g. `VAR_TBB`, `VAR_OPENMP`, ...
##### Setting environment variable in Windows
### Setting environment variable in Windows
In terminal or cmd-file (bat-file):
```.bat
set MY_ENV_VARIABLE=true
@ -30,7 +30,7 @@ In GUI:
- In new window click on the "Environment variables" button
- Add an entry to the "User variables" list
##### Setting environment variable in Linux
### Setting environment variable in Linux
In terminal or shell script:
```.sh
@ -42,7 +42,7 @@ or as a single command:
MY_ENV_VARIABLE=true ./my_app
```
##### Setting environment variable in Python
### Setting environment variable in Python
```.py
import os
@ -51,7 +51,7 @@ import cv2 # variables set after this may not have effect
```
### Types
## Types
- _non-null_ - set to anything to enable feature, in some cases can be interpreted as other types (e.g. path)
| ⭐ OPENCV_FOR_THREADS_NUM | num | 0 | set number of threads |
@ -112,7 +112,7 @@ Links:
| OPENCV_FOR_OPENMP_DYNAMIC_DISABLE | bool | false | use single OpenMP thread |
### backends
## backends
OPENCV_LEGACY_WAITKEY
Some modules have multiple available backends, following variables allow choosing specific backend or changing default priorities in which backends will be probed (e.g. when opening a video file).
@ -128,7 +128,7 @@ Some modules have multiple available backends, following variables allow choosin
| OPENCV_VIDEOIO_PRIORITY_LIST | string, `,`-separated | | list of videoio backends in priority order |
### plugins
## plugins
Some external dependencies can be detached into a dynamic library, which will be loaded at runtime (plugin). Following variables allow changing default search locations and naming pattern for these plugins.
| name | type | default | description |
|------|------|---------|-------------|
@ -141,7 +141,7 @@ Some external dependencies can be detached into a dynamic library, which will be
| OPENCV_VIDEOIO_PLUGIN_PATH | paths | | directories to search for _videoio_ plugins |
**Note:** OpenCL device specification format is `<Platform>:<CPU|GPU|ACCELERATOR|nothing=GPU/CPU>:<deviceName>`, e.g. `AMD:GPU:`
@ -170,7 +170,7 @@ Some external dependencies can be detached into a dynamic library, which will be
| OPENCV_OPENCL_FORCE | bool | false | force running OpenCL kernel even if usual conditions are not met (e.g. dst.isUMat) |
| OPENCV_OPENCL_PERF_CHECK_BYPASS | bool | false | force running OpenCL kernel even if usual performance-related conditions are not met (e.g. image is very small) |
##### SVM (Shared Virtual Memory) - disabled by default
### SVM (Shared Virtual Memory) - disabled by default
**Note:** In the table below `dump_base_name` equals to `ocv_dnn_net_%05d_%02d` where first argument is internal network ID and the second - dump level.
| name | type | default | description |
|------|------|---------|-------------|
@ -240,7 +240,7 @@ Some external dependencies can be detached into a dynamic library, which will be
**Note:** extra FFmpeg options should be pased in form `key;value|key;value|key;value`, for example `hwaccel;cuvid|video_codec;h264_cuvid|vsync;0` or `vcodec;x264|vprofile;high|vlevel;4.0`
| name | type | default | description |
@ -288,7 +288,7 @@ Some external dependencies can be detached into a dynamic library, which will be
There are two kinds of videoio backends: built-in backends and plugins which will be loaded at runtime (since OpenCV 4.1.0). Use functions cv::videoio_registry::getBackends, cv::videoio_registry::hasBackend and cv::videoio_registry::getBackendName to check actual presence of backend during runtime.
@ -71,7 +74,9 @@ To enable dynamically-loaded videoio backend (currently supported: GStreamer and
@note Don't forget to clean CMake cache when switching between these two modes
#### Use 3rd party drivers or cameras
Use 3rd party drivers or cameras
--------------------------------
Many industrial cameras or some video I/O devices don't provide standard driver interfaces
for the operating system. Thus you can't use VideoCapture or VideoWriter with these devices.
@ -83,6 +88,7 @@ It is a common case that these libraries read/write images from/to a memory buff
possible to make a `Mat` header for memory buffer (user-allocated data) and process it
in-place using OpenCV functions. See cv::Mat::Mat() for more details.
Maksim Shabunin
9 months ago
committed by
GitHub