Objc binding
* Initial work on Objective-C wrapper
* Objective-C generator script; update manually generated wrappers
* Add Mat tests
* Core Tests
* Imgproc wrapper generation and tests
* Fixes for Imgcodecs wrapper
* Miscellaneous fixes. Swift build support
* Objective-C wrapper build/install
* Add Swift wrappers for videoio/objdetect/feature2d
* Framework build;iOS support
* Fix toArray functions;Use enum types whenever possible
* Use enum types where possible;prepare test build
* Update test
* Add test runner scripts for iOS and macOS
* Add test scripts and samples
* Build fixes
* Fix build (cmake 3.17.x compatibility)
* Fix warnings
* Fix enum name conflicting handling
* Add support for document generation with Jazzy
* Swift/Native fast accessor functions
* Add Objective-C wrapper for calib3d, dnn, ml, photo and video modules
* Remove IntOut/FloatOut/DoubleOut classes
* Fix iOS default test platform value
* Fix samples
* Revert default framework name to opencv2
* Add converter util functions
* Fix failing test
* Fix whitespace
* Add handling for deprecated methods;fix warnings;define __OPENCV_BUILD
* Suppress cmake warnings
* Reduce severity of "jazzy not found" log message
* Fix incorrect #include of compatibility header in ios.h
* Use explicit returns in subscript/get implementation
* Reduce minimum required cmake version to 3.15 for Objective-C/Swift binding
Fixes the help for `--features`, previously listed all possible values as default value.
Also adds the default value to the help for two other arguments
* improved fitEllipse and fitEllipseDirect accuracy in singular or close-to-singular cases (see issue #9923)
* scale points using double precision
* added normalization to fitEllipseAMS as well; fixed Java test case by raising the tolerance (it's unclear what is the correct result in this case).
* improved point perturbation a bit. make the code a little bit more clear
* trying to fix Java fitEllipseTest by slightly raising the tolerance threshold
* synchronized C++ version of Java's fitEllipse test
* removed trailing whitespaces
* fixed#17044
1. fixed Python part of the tutorial about using OpenCV XML-YAML-JSON I/O functionality from C++ and Python.
2. added startWriteStruct() and endWriteStruct() methods to FileStorage
3. modifed FileStorage::write() methods to make them work well inside sequences, not only mappings.
* try to fix the doc builder
* added Python regression test for FileStorage I/O API ([TODO] iterating through long sequences can be very slow)
* fixed yaml testing
Fix Test Case: in latest version, window.cv is a promise instance that makes most test case failed.
* Fix Browser Test Case: In latest version, window.cv is a promise instance
In latest version of opencv.js, window.cv is promise instance.
So that most of the test cases is run failed.
This commit is to fix browser test case.
* Add comment for backward compatible
Add comments for backward compatible
The legacy `includedir` was removed in 4.0 (https://github.com/opencv/opencv/pull/12477) but it was not removed from the `.pc` file.
This causes issues when trying to link against OpenCV using pkg-config in CMake.
* Fix integer overflow in parseOption().
Previous code does not work for values like 100000MB.
* Fix warning during 32-bit build on inactive code path.
* fix build without C++11
* fix bug for CHECK issue
* remove chack for bpp
* add test for tif file
* add test for tiff file
* change the test name
* use proper bpp value, use clear test names
* add eigen tensor conversion functions
* add eigen tensor conversion tests
* add support for column major order
* update eigen tensor tests
* fix coding style and add conditional compilation
* fix conditional compilation checks
* remove whitespace
* rearrange functions for easier reading
* reformat function documentation and add tensormap unit test
* cleanup documentation of unit test
* remove condition duplication
* check Eigen major version, not minor version
* restrict to Eigen v3.3.0+
* add documentation note and add type checking to cv2eigen_tensormap()
- reworked variant::operator(T&&) and varaint::variant(T&&) to be more
concise and signature accurate with C++17 specification
- restricted cv::detail::OpaqueRef::OpaqueRef(T&&) to not substitute
copy/move ctors
- moved common additions to C++11 version of std <type_traits> to
separte header
* imgproc: templmatch: Add support for mask for all methods
Add support for masked template matching. Fix/scrub old implementation
for masked matching, as it did partly not even really do a meaningful
masking, and only supported limited template matching methods.
Add documentation including formulas for masked matching.
* imgproc: test: Add tests for masked template matching
Test accuracy by comparing to naive implementation for one point.
Test compatibility/correctness by comparing results without mask and
with all ones mask.
All tests are done for all methods, all supported depths, and for 1 and
3 channels.
* imgproc: test: templmatch: Add test for crossCorr
Add a test for the crossCorr function in templmatch.cpp. crossCorr() had
to be added to exported functions to be testable.
This test can maybe help to identify the problem with template matching
on MacOSX.
* fix: Fixed wrong evaluations of the MatExpr on Clang
* fix: removed crossCorr from public interface.
If it should be exported, it should be done as separate PR.
Co-authored-by: Vadim Levin <vadim.levin@xperience.ai>
* Fixed indexing in prefilter
* Initialised prefilter
* Initialised prefilter with value initialisation
* Added TC to trigger different Mem Allocs in BufferBM
* Optimize cases with only needed conditions
- moved "standalone" aliases of cv types to "opencv_includes.hpp" to
keep responsibility principle aplied
- introduced correct aliasing for "descr_of(Mat)" function for
standalone case
- added missing include in `gapi/own/mat.hpp`
Updated the Windows Visual Studio Image Watch tutorial to include download links to the latest versions of Visual Studio Image Watch for newer Visual Studio versions.
cuda4dnn: optimizations for swish, mish, sigmoid, region, resize based ops, transpose, identity-conv fusion
* bunch of optimizations
* more accurate implementation for mish
* feature: Extend VideoWriter to accept vector of parameters
- Add additional constructor and `open` method for `VideoWriter`
those accept a vector of parameters
- Move actual implementation of the `VideoWriter::open` to general method
which accepts vector of parameters
- Propagate parsed parameters map up to actual video backend construction
* fix: Change VideoWriter constructor description to suppress doc warning
* refactor: Rollback newlines changes
* feature: Changed VideoWriter parameters workflow
* feature: Log unused parameters in VideoWriter open
* doc: Fix VideoWriter `isColor` parameter description
* fix: int to bool VC++ conversion warning
* doc: Remove information about `isColor` flag usage.
I believe you are using the wrong version of open() on line 28 - adding deviceID + appId together. It's better to use the new version of .open() taking two integers as parameter.
G-API: Laplacian and bilateralFilter standard kernels
* Added Laplacian kernel and tests
* Added: Laplacian kernel, Bilateral kernel (CPU, GPU); Performance and accuracy tests for this kernels
* Changed tolerance for GPU test
* boner
* Some changes with alignment; Tests's parameters are the same as for OCV
* Cut tests
* Compressed tests
* Minor changes (rsrt bb)
* Returned types
- kernel added to a cv::gapi::video namespace
- tests to check a kernels (based on cv::video tests for cv::buildOpticalFlowPyramid())
- tests for a combined G-API-pipeline (buildOpticalFlowPyramid() -> calcOpticalFlowPyrLK())
- tests for internal purposes added
- custom function for comparison in tests implemented
Added a sample file for qrcode detection in python
* sample python file for qrcode detection added in samples/python
* input taken using argparse and the indents were removed
* Removed unused variables
* updated the format and removed unused variables
Removed the use of global variables and used parameterised contructor instead
=set multi detection true by default
* added detection from camera
* samples(python): coding style in qrcode.py
- It is safe to remove `explicit` keyword for constructors with 1
argument, because it is C++ specific keyword and does not affect any of
the generated binding.
* LineVirtualIterator
Proposal of LineVirtualIterator, an alternative to "LineIterator not attached to any mat".
This is basically the same implementation, replacing the address difference by a single "offset" variable. elemsize becomes irrelevant and considered to be 1. "step" is thus equal to size.width since no stride is expected.
* Update drawing.cpp
fixed warning
* improvement of LineVirtualIterator
instead of being too conservative, the new implementation gets rid of "offset/step" and only keeps a "Point currentPos" up to date.
left_to_right is renamed to forceLeftToRight as suggested (even for the old LineIterator)
assert() replaced by CV_Assert() (even for the old LineIterator)
* fixed implementation
+fixed last commit so that LineVirtualIterator gives at least the same results as LineIterator
+added a new constructor that does not require any Size, so that no clipping is done and iteration occurs from pt1 to pt2. This is done by adding a spatial offset to pt1 and pt2 so that the same implementation is used, the size being in that case the spatial size between pt1 and pt2
* Update imgproc.hpp
fixed warnings
* Update drawing.cpp
fixed whitespace
* Update drawing.cpp
trailing whitespace
* Update imgproc.hpp
+added a new constructor that takes a Rect rather than a Size. It computes the line pt1->pt2 that clips that rect.
Yet again, this is still based on the same implementation, thanks to the Size and the currentPosOffset that can artifically consider the origin of the rect at (0,0)
* revert changes
revert changes on original LineIterator implementation, that will be superseded by the new LineVirtualIterator anyway
* added test of LineVirtualIterator
* More tests
* refactoring
Use C++11 chained constructors
Improved code style
* improve test
Added offset as random test data.
* fixed order of initialization
* merged LineIterator and VirtualLineIterator
* merged LineIterator & VirtualLineIterator
* merged LineIterator & VirtualLineIterator
* merged LineIterator & VirtualLineIterator
* made LineIterator::operator ++() more efficient
added one perfectly predictable check; in theory, since ptmode is set in the end of the constructor in the header file, the compiler can figure out that it's always true/false and eliminate the check from the inline `LineIterator::operator++()` completely
* optimized Line() function
in the most common case (CV_8UC3) eliminated the check from the loop
Co-authored-by: Vadim Pisarevsky <vadim.pisarevsky@gmail.com>
* Update OpenCVFindVA_INTEL.cmake
When set env VA_INTEL_IOCL_ROOT, "if($ENV{VA_INTEL_IOCL_ROOT})" don't work.
My modification as follow.
- if($ENV{VA_INTEL_IOCL_ROOT})
+ if(DEFINED ENV{VA_INTEL_IOCL_ROOT})
Refer: https://cmake.org/cmake/help/latest/variable/ENV.html
* based on merge comment, update code
- opencv_gapi module is linked with opencv_video module (optional dependency)
- kernels added to a new cv::gapi::video namespace and a brand new files created to provide gapi_video environment
- there are 2 different kernels as G-API should provide GMat AND GArray<GMat> implementation: cv::calcOptFlowPyrLK doesn't calculate pyramids if vector<Mat> is given so just the cast GMat -> GArray<GMat> wouldn't represent all the cv:: functionality
- tests to check both kernels (based on cv::video tests for cv::calcOpticalFlowPyrLK())
- tests for internal purposes added
- vectors<T> comparison in tests implemented
- new (and old too) common test structures refactored to avoid code copypasting
- "modules/gapi/test/common/gapi_video_tests_common.hpp" created to share some code snippets between perf and acc tests and avoid code copypasting
added estimateTranslation3D to calib3d/ptsetreg
* added estimateTranslation3D; follows API and implementation structure for estimateAffine3D, but only allows for translation
* void variables in null function to suppress compiler warnings
* added test for estimateTranslation3D
* changed to Matx13d datatype for translation vector in ptsetreg and test; used short license in test
* removed iostream include
* calib3d: code cleanup
- cv::gapi::goodFeaturesToTrack() kernel is implemented
- tests (for exact check with cv::goodFeaturesToTrack() and for internal cases) are implemented
- a custom comparison function for vectors and a custom test fixture implemented
- some posiible issues as wrong/inexact sorting of two compared vectors are
not taken into account
- initializations of an input Mat using a picture from opencv_extra implemented (function from gapi_streaming_test used)
The PREDEFINED setting for had a space between the define name and the equal sign and this is not allowed, it results in the warning:
```
error: Illegal PREDEFINED format '=', no define name specified
```
according to the documentation explicitly states that no space is allowed:
> The PREDEFINED tag can be used to specify one or more macro names that are defined before the preprocessor is started (similar to the -D option of e.g. gcc). The argument of the tag is a list of macros of the form: name or name=definition (no spaces). If the definition and the "=" are omitted, "=1" is assumed. To prevent a macro definition from being undefined via #undef or recursively expanded use the := operator instead of the = operator.
G-API: Unification of own:: Scalar with cv:: Scalar
* cvdefs.hpp
* Small changes
* Deowned Scalar. Does't work
* Something
* Removed to_ocv for Scalar
* Clear code
* Deleted whitespaces
* Added include<..own/scalar.hpp in cvdefs.hpp.
* Long string split on two now
* Comment about scalar
* Comment about crutch
* Removed second varible in scalar_wrapper
* Changed wrapper for scalar, alignment
* Alignment
* Whitespaces
* Removed scalar_wrapper
Jpeg2000 OpenJPEG port
* OpenJPEG based JPEG2000 decoder implementation
Currently, the following input color spaces and depth conversions are
supported:
- 8 bit -> 8 bit
- 16 bit -> 16 bit (IMREAD_UNCHANGED, IMREAD_ANYDEPTH)
- RGB(a) -> BGR
- RGBA -> BGRA (IMREAD_UNCHANGED)
- Y(a) -> Y(a) (IMREAD_ANYCOLOR, IMREAD_GRAY, IMREAD_UNCHANGED))
- YCC -> Y (IMREAD_GRAY)
* Check for OpenJPEG availability
This enables OpenJPEG based JPEG2000 imread support by default, which
can be disabled by -DWITH_OPENJPEG=OFF. In case OpenJPEG is enabled
and found, any checks for Jasper are skipped.
* Implement precision downscaling for precision > 8 without IMREAD_UNCHANGED
With IMREAD_UNCHANGED, values are kept from the input image, without it
components are downscaled to CV_8U range.
* Enable Jpeg2K tests when OpenJPEG is available
* Add support for some more color conversions
Support IMREAD_GRAY when input color space is RGB or unspecified.
Support YUV input color space for BGR output.
* fix: problems with unmanaged memory
* fix: CMake warning - HAVE_OPENJPEG is undefined
Removed trailing whitespaces
* fix: CMake find_package OpenJPEG add minimal version
* Basic JPEG2K encoder
Images with depth CV_8U and CV_16U are supported, with 1 to 4 channels.
* feature: Improved code for OpenJPEG2000 encoder/decoder
- Removed code duplication
- Added error handlers
- Extracted functions
* feature: Update conversion openjpeg array from/to Mat
* feature: Extend ChannelsIterator to fulfill RandomAccessIterator named requirements
- Removed channels split in copyFromMatImpl. With ChannelsIterator no allocations are performed.
- Split whole loop into 2 parts in copyToMat -> where std::copy and std::transforms are called.
* fix: Applied review comments.
- Changed `nullptr` in CV_LOG* functions to `NULL`
- Added `falls through` comment in decoder color space `switch`
- Added warning about unsupported parameters for the encoder
* feature: Added decode from in-memory buffers.
Co-authored-by: Vadim Levin <vadim.levin@xperience.ai>
message(WARNING"InferenceEngine version has not been set, 2020.1 will be used by default. Set INF_ENGINE_RELEASE variable if you experience build errors.")
message(WARNING"InferenceEngine version has not been set, 2020.4 will be used by default. Set INF_ENGINE_RELEASE variable if you experience build errors.")
endif()
set(INF_ENGINE_RELEASE"2020010000"CACHESTRING"Force IE version, should be in form YYYYAABBCC (e.g. 2020.1.0.2 -> 2020010002)")
set(INF_ENGINE_RELEASE"2020040000"CACHESTRING"Force IE version, should be in form YYYYAABBCC (e.g. 2020.1.0.2 -> 2020010002)")
It can be seen that almost all OpenCV functions receive InputArray type.
What is it, and how can I understand the actual input types of parameters?
This is the proxy class for passing read-only input arrays into OpenCV functions.
Inside a function you should use cv::_InputArray::getMat() method to construct
a matrix header for the array (without copying data). cv::_InputArray::kind() can be used to distinguish Mat from vector<> etc.
but normally it is not needed.
for more information see cv::_InputArray
- **Which is more efficient, use contourArea() or count number of ROI non-zero pixels?**
In a case where you only want relative areas, which one is faster to compute:
calculate a contour area or count the number of ROI non-zero pixels?
cv::contourArea() uses Green formula (http://en.wikipedia.org/wiki/Green's_theorem) to compute the area, therefore its complexity is O(contour_number_of_vertices). Counting non-zero pixels in the ROI is O(roi_width*roi_height) algorithm, i.e. much slower. Note, however, that because of finite, and quite low, resolution of the raster grid, the two algorithms will give noticeably different results. For large and square-like contours the error will be minimal. For small and/or oblong contours the error can be quite large.
Compatibility page. FAQ migrated to the project [wiki](https://github.com/opencv/opencv/wiki/FAQ).
You don't have to build your own copy if you simply want to start using it. Refer the Using Opencv.js tutorial for steps on getting a prebuilt copy from our releases or online documentation.
@@ -4,7 +4,7 @@ Using OpenCV.js {#tutorial_js_usage}
Steps
-----
In this tutorial, you will learn how to include and start to use `opencv.js` inside a web page.
In this tutorial, you will learn how to include and start to use `opencv.js` inside a web page. You can get a copy of `opencv.js` from `opencv-{VERSION_NUMBER}-docs.zip` in each [release](https://github.com/opencv/opencv/releases), or simply download the prebuilt script from the online documentations at "https://docs.opencv.org/{VERISON_NUMBER}/opencv.js" (For example, [https://docs.opencv.org/3.4.0/opencv.js](https://docs.opencv.org/3.4.0/opencv.js). Use `master` if you want the latest build). You can also build your own copy by following the tutorial on Build Opencv.js.
### Create a web page
@@ -44,7 +44,7 @@ To run this web page, copy the content above and save to a local index.html file
Set the URL of `opencv.js` to `src` attribute of \<script\> tag.
@note For this tutorial, we host `opencv.js` at same folder as index.html.
@note For this tutorial, we host `opencv.js` at same folder as index.html. You can also choose to use the URL of the prebuilt `opencv.js` in our online documentation.
In this chapter, we will understand the concepts of k-Nearest Neighbour (kNN) algorithm.
In this chapter, we will understand the concepts of the k-Nearest Neighbour (kNN) algorithm.
Theory
------
kNN is one of the simplest of classification algorithms available for supervised learning. The idea
is to search for closest match of the test data in feature space. We will look into it with below
kNN is one of the simplest classification algorithms available for supervised learning. The idea
is to search for the closest match(es) of the test data in the feature space. We will look into it with the below
image.

In the image, there are two families, Blue Squares and Red Triangles. We call each family as
**Class**. Their houses are shown in their town map which we call feature space. *(You can consider
a feature space as a space where all datas are projected. For example, consider a 2D coordinate
space. Each data has two features, x and y coordinates. You can represent this data in your 2D
coordinate space, right? Now imagine if there are three features, you need 3D space. Now consider N
features, where you need N-dimensional space, right? This N-dimensional space is its feature space.
In our image, you can consider it as a 2D case with two features)*.
In the image, there are two families: Blue Squares and Red Triangles. We refer to each family as
a **Class**. Their houses are shown in their town map which we call the **Feature Space**. You can consider
a feature space as a space where all data are projected. For example, consider a 2D coordinate
space. Each datum has two features, a x coordinate and a y coordinate. You can represent this datum in your 2D
coordinate space, right? Now imagine that there are three features, you will need 3D space. Now consider N
features: you need N-dimensional space, right? This N-dimensional space is its feature space.
In our image, you can consider it as a 2D case with two features.
Now a new member comes into the town and creates a new home, which is shown as green circle. He
should be added to one of these Blue/Red families. We call that process, **Classification**. What we
do? Since we are dealing with kNN, let us apply this algorithm.
Now consider what happens if a new member comes into the town and creates a new home, which is shown as the green circle. He
should be added to one of these Blue or Red families (or *classes*). We call that process, **Classification**. How exactly should this new member be classified? Since we are dealing with kNN, let us apply the algorithm.
One method is to check who is his nearest neighbour. From the image, it is clear it is the Red
Triangle family. So he is also added into Red Triangle. This method is called simply **Nearest
Neighbour**, because classification depends only on the nearest neighbour.
One simple method is to check who is his nearest neighbour. From the image, it is clear that it is a member of the Red
Triangle family. So he is classified as a Red Triangle. This method is called simply **Nearest Neighbour** classification, because classification depends only on the *nearest neighbour*.
But there is a problem with that. Red Triangle may be the nearest. But what if there are lot of Blue
Squares near to him? Then Blue Squares have more strength in that locality than Red Triangle. So
just checking nearest one is not sufficient. Instead we check some k nearest families. Then whoever
is majority in them, the new guy belongs to that family. In our image, let's take k=3, ie 3 nearest
families. He has two Red and one Blue (there are two Blues equidistant, but since k=3, we take only
But there is a problem with this approach! Red Triangle may be the nearest neighbour, but what if there are also a lot of Blue
Squares nearby? Then Blue Squares have more strength in that locality than Red Triangles, so
just checking the nearest one is not sufficient. Instead we may want to check some **k** nearest families. Then whichever family is the majority amongst them, the new guy should belong to that family. In our image, let's take k=3, i.e. consider the 3 nearest
neighbours. The new member has two Red neighbours and one Blue neighbour (there are two Blues equidistant, but since k=3, we can take only
one of them), so again he should be added to Red family. But what if we take k=7? Then he has 5 Blue
families and 2 Red families. Great!! Now he should be added to Blue family. So it all changes with
value of k. More funny thing is, what if k = 4? He has 2 Red and 2 Blue neighbours. It is a tie !!!
So better take k as an odd number. So this method is called **k-Nearest Neighbour** since
classification depends on k nearest neighbours.
neighbours and 2 Red neighbours and should be added to the Blue family. The result will vary with the selected
value of k. Note that if k is not an odd number, we can get a tie, as would happen in the above case with k=4. We would see that our new member has 2 Red and 2 Blue neighbours as his four nearest neighbours and we would need to choose a method for breaking the tie to perform classification. So to reiterate, this method is called **k-Nearest Neighbour** since
classification depends on the *k nearest neighbours*.
Again, in kNN, it is true we are considering k neighbours, but we are giving equal importance to
all, right? Is it justice? For example, take the case of k=4. We told it is a tie. But see, the 2
Red families are more closer to him than the other 2 Blue families. So he is more eligible to be
added to Red. So how do we mathematically explain that? We give some weights to each family
depending on their distance to the new-comer. For those who are near to him get higher weights while
those are far away get lower weights. Then we add total weights of each family separately. Whoever
gets highest total weights, new-comer goes to that family. This is called **modified kNN**.
all, right? Is this justified? For example, take the tied case of k=4. As we can see, the 2
Red neighbours are actually closer to the new member than the other 2 Blue neighbours, so he is more eligible to be
added to the Red family. How do we mathematically explain that? We give some weights to each neighbour
depending on their distance to the new-comer: those who are nearer to him get higher weights, while
those that are farther away get lower weights. Then we add the total weights of each family separately and classify the new-comer as part of whichever family
received higher total weights. This is called **modified kNN** or **weighted kNN**.
So what are some important things you see here?
- You need to have information about all the houses in town, right? Because, we have to check
the distance from new-comer to all the existing houses to find the nearest neighbour. If there
are plenty of houses and families, it takes lots of memory, and more time for calculation
also.
- There is almost zero time for any kind of training or preparation.
- Because we have to check
the distance from the new-comer to all the existing houses to find the nearest neighbour(s), you need to have information about all of the houses in town, right? If there are plenty of houses and families, it takes a lot of memory, and also more time for calculation.
- There is almost zero time for any kind of "training" or preparation. Our "learning" involves only memorizing (storing) the data, before testing and classifying.
Now let's see it in OpenCV.
Now let's see this algorithm at work in OpenCV.
kNN in OpenCV
-------------
@@ -67,11 +61,11 @@ We will do a simple example here, with two families (classes), just like above.
chapter, we will do an even better example.
So here, we label the Red family as **Class-0** (so denoted by 0) and Blue family as **Class-1**
(denoted by 1). We create 25 families or 25 training data, and label them either Class-0 or Class-1.
We do all these with the help of Random Number Generator in Numpy.
(denoted by 1). We create 25 neighbours or 25 training data, and label each of them as either part of Class-0 or Class-1.
We can do this with the help of a Random Number Generator from NumPy.
Then we plot it with the help of Matplotlib. Red families are shown as Red Triangles and Blue
families are shown as Blue Squares.
Then we can plot it with the help of Matplotlib. Red neighbours are shown as Red Triangles and Blue
neighbours are shown as Blue Squares.
@code{.py}
import cv2 as cv
import numpy as np
@@ -80,36 +74,36 @@ import matplotlib.pyplot as plt
# Feature set containing (x,y) values of 25 known/training data
# How to run deep networks on Android device {#tutorial_dnn_android}
@prev_tutorial{tutorial_dnn_halide_scheduling}
@next_tutorial{tutorial_dnn_yolo}
## Introduction
In this tutorial you'll know how to run deep learning networks on Android device
using OpenCV deep learning module.
@@ -12,7 +15,7 @@ Tutorial was written for the following versions of corresponding software:
- Download and install Android Studio from https://developer.android.com/studio.
- Get the latest pre-built OpenCV for Android release from https://github.com/opencv/opencv/releases and unpack it (for example, `opencv-4.3.0-android-sdk.zip`).
- Get the latest pre-built OpenCV for Android release from https://github.com/opencv/opencv/releases and unpack it (for example, `opencv-4.4.0-android-sdk.zip`).
- Download MobileNet object detection model from https://github.com/chuanqi305/MobileNet-SSD. We need a configuration file `MobileNetSSD_deploy.prototxt` and weights `MobileNetSSD_deploy.caffemodel`.
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.