fixed ?? marks; fixed missing highlighting in some of the sections
This commit is contained in:
Vadim Pisarevsky
parent
e863c3d5f6
commit
e9a5bbc003
@ -1025,14 +1025,12 @@ Mat::Mat
|
||||
|
||||
:param colRange: The range of the ``m`` 's columns to take. Use ``Range::all()`` to take all the columns.
|
||||
|
||||
:param ranges: The array of selected ranges of ``m`` along each dimensionality
|
||||
|
||||
.
|
||||
:param ranges: The array of selected ranges of ``m`` along each dimensionality.
|
||||
|
||||
:param expr: Matrix expression. See :ref:`MatrixExpressions`.
|
||||
|
||||
These are various constructors that form a matrix. As noticed in the ??
|
||||
, often the default constructor is enough, and the proper matrix will be allocated by an OpenCV function. The constructed matrix can further be assigned to another matrix or matrix expression, in which case the old content is de-referenced, or be allocated with
|
||||
These are various constructors that form a matrix. As noticed in the :ref:`AutomaticAllocation`,
|
||||
often the default constructor is enough, and the proper matrix will be allocated by an OpenCV function. The constructed matrix can further be assigned to another matrix or matrix expression, in which case the old content is de-referenced, or be allocated with
|
||||
:ref:`Mat::create` .
|
||||
|
||||
.. index:: Mat::Mat
|
||||
@ -1623,7 +1621,7 @@ Mat::locateROI
|
||||
|
||||
Locates the matrix header within a parent matrix.
|
||||
|
||||
:param wholeSize: An output parameter that contains the size of the whole matrix, which ``*this`` is a part of.??
|
||||
:param wholeSize: An output parameter that contains the size of the whole matrix, which contains ``*this`` is a part.
|
||||
|
||||
:param ofs: An output parameter that contains an offset of ``*this`` inside the whole matrix.
|
||||
|
||||
|
||||
@ -1,6 +1,8 @@
|
||||
Clustering
|
||||
==========
|
||||
|
||||
.. highlight:: cpp
|
||||
|
||||
.. index:: kmeans
|
||||
|
||||
.. _kmeans:
|
||||
@ -8,7 +10,7 @@ Clustering
|
||||
kmeans
|
||||
------
|
||||
|
||||
.. c:function:: double kmeans( const Mat\& samples, int clusterCount, Mat\& labels, TermCriteria termcrit, int attempts, int flags, Mat* centers )
|
||||
.. c:function:: double kmeans( const Mat& samples, int clusterCount, Mat& labels, TermCriteria termcrit, int attempts, int flags, Mat* centers )
|
||||
|
||||
Finds centers of clusters and groups input samples around the clusters.
|
||||
|
||||
@ -18,7 +20,7 @@ kmeans
|
||||
|
||||
:param labels: Input/output integer array that stores the cluster indices for every sample.
|
||||
|
||||
:param termcrit: Flag to specify the maximum number of iterations and/or accuracy (distance the centers can move by between subsequent iterations??).
|
||||
:param termcrit: Flag to specify the maximum number of iterations and/or the desired accuracy. The accuracy is specified as ``termcrit.epsilon``. As soon as each of the cluster centers moves by less than ``termcrit.epsilon`` on some iteration, the algorithm stops.
|
||||
|
||||
:param attempts: Flag to specify how many times the algorithm is executed using different initial labelings. The algorithm returns the labels that yield the best compactness (see the last function parameter).
|
||||
|
||||
@ -57,7 +59,7 @@ partition
|
||||
-------------
|
||||
.. c:function:: template<typename _Tp, class _EqPredicate> int
|
||||
|
||||
.. c:function:: partition( const vector<_Tp>\& vec, vector<int>\& labels, _EqPredicate predicate=_EqPredicate())
|
||||
.. c:function:: partition( const vector<_Tp>& vec, vector<int>& labels, _EqPredicate predicate=_EqPredicate())
|
||||
|
||||
Splits an element set into equivalency classes.
|
||||
|
||||
|
||||
@ -8,13 +8,9 @@ The boundaries of the shapes can be rendered with antialiasing (implemented only
|
||||
All the functions include the parameter ``color`` that uses an RGB value (that may be constructed
|
||||
with ``CV_RGB`` or the :ref:`Scalar` constructor
|
||||
) for color
|
||||
images and brightness for grayscale images. For color images, the order?? channel
|
||||
is normally
|
||||
*Blue, Green, Red*.
|
||||
This is what
|
||||
:func:`imshow`,
|
||||
:func:`imread`, and
|
||||
:func:`imwrite` expect.
|
||||
images and brightness for grayscale images. For color images, the channel ordering
|
||||
is normally *Blue, Green, Red*.
|
||||
This is what :func:`imshow`, :func:`imread`, and :func:`imwrite` expect.
|
||||
So, if you form a color using the
|
||||
:ref:`Scalar` constructor, it should look like:
|
||||
|
||||
@ -52,7 +48,7 @@ circle
|
||||
|
||||
:param lineType: Type of the circle boundary. See :func:`line` description.
|
||||
|
||||
:param shift: Number of fractional bits in the center?? coordinates, and radius value.
|
||||
:param shift: Number of fractional bits in the center's coordinates and in the radius value.
|
||||
|
||||
The function ``circle`` draws a simple or filled circle with a given center and radius.
|
||||
|
||||
@ -107,7 +103,7 @@ ellipse
|
||||
|
||||
:param lineType: Type of the ellipse boundary. See :func:`line` description.
|
||||
|
||||
:param shift: Number of fractional bits in the center?? coordinates and axes' values.
|
||||
:param shift: Number of fractional bits in the center's coordinates and axes' values.
|
||||
|
||||
The functions ``ellipse`` with less parameters draw an ellipse outline, a filled ellipse, an elliptic arc, or a filled ellipse sector.
|
||||
A piecewise-linear curve is used to approximate the elliptic arc boundary. If you need more control of the ellipse rendering, you can retrieve the curve using
|
||||
|
||||
@ -2,6 +2,8 @@
|
||||
Introduction
|
||||
************
|
||||
|
||||
.. highlight:: cpp
|
||||
|
||||
OpenCV (Open Source Computer Vision Library: http://opencv.willowgarage.com/wiki/) is an open-source BSD-licensed library that includes several hundreds computer vision algorithms. The document describes the so-called OpenCV 2.x API, which is essentially a C++ API, as opposite to the C-based OpenCV 1.x API. The latter is described in opencv1x.pdf.
|
||||
|
||||
OpenCV has a modular structure, which means that the package includes several shared or static libraries. The modules are:
|
||||
@ -22,7 +24,7 @@ API Concepts
|
||||
================
|
||||
|
||||
*``cv``* Namespace
|
||||
----------------
|
||||
------------------
|
||||
|
||||
All the OpenCV classes and functions are placed into the *``cv``* namespace. Therefore, to access this functionality from your code, use the ``cv::`` specifier or ``using namespace cv;`` directive:
|
||||
|
||||
@ -81,7 +83,7 @@ First of all, ``std::vector``, ``Mat``, and other data structures used by the fu
|
||||
// matrix will be deallocated, since it is not referenced by anyone
|
||||
C = C.clone();
|
||||
|
||||
Therefore, the use of ``Mat`` and other basic structures is simple. But what about high-level classes or even user data types created without automatic memory management in mind? For them OpenCV offers the ``Ptr<>`` template class that is similar to ``std::shared_ptr`` from C++ TR1. So, instead of using plain pointers::
|
||||
Therefore, the use of ``Mat`` and other basic structures is simple. But what about high-level classes or even user data types created without taking automatic memory management into account? For them OpenCV offers the ``Ptr<>`` template class that is similar to ``std::shared_ptr`` from C++ TR1. So, instead of using plain pointers::
|
||||
|
||||
T* ptr = new T(...);
|
||||
|
||||
@ -91,9 +93,7 @@ you can use::
|
||||
|
||||
That is, ``Ptr<T> ptr`` incapsulates a pointer to a ``T`` instance and a reference counter associated with the pointer. See ``Ptr`` description for details.
|
||||
|
||||
.. todo::
|
||||
|
||||
Should we replace Ptr<> with the semi-standard shared_ptr<>?
|
||||
.. _AutomaticAllocation:
|
||||
|
||||
Automatic Allocation of the Output Data
|
||||
---------------------------------------
|
||||
@ -126,7 +126,7 @@ Here is the example: ::
|
||||
return 0;
|
||||
}
|
||||
|
||||
The array ``frame`` is automatically allocated by the ``>>`` operator, since the video frame resolution and bit-depth is known to the video capturing module. The array ``edges`` is automatically allocated by the ``cvtColor`` function. It has the same size and the bit-depth as the input array. The number of channels is 1 because the color conversion code ``CV_BGR2GRAY`` is passed (that means color to grayscale conversion??). Note that ``frame`` and ``edges`` are allocated only once during the first execution of the loop body, since all the next video frames have the same resolution. If you somehow change the video resolution, the arrays are automatically reallocated.
|
||||
The array ``frame`` is automatically allocated by the ``>>`` operator, since the video frame resolution and bit-depth is known to the video capturing module. The array ``edges`` is automatically allocated by the ``cvtColor`` function. It has the same size and the bit-depth as the input array. The number of channels is 1 because the color conversion code ``CV_BGR2GRAY`` is passed, which means color to grayscale conversion. Note that ``frame`` and ``edges`` are allocated only once during the first execution of the loop body, since all the next video frames have the same resolution. If you somehow change the video resolution, the arrays are automatically reallocated.
|
||||
|
||||
The key component of this technology is the ``Mat::create`` method. It takes the desired array size and type. If the array already has the specified size and type, the method does nothing. Otherwise, it releases the previously allocated data, if any (this part involves decrementing the reference counter and comparing it with zero), and then allocates a new buffer of the required size. Most functions call this the ``Mat::create`` method for each output array and so the automatic output data allocation is implemented.
|
||||
|
||||
@ -163,9 +163,6 @@ There is a limited fixed set of primitive data types the library can operate on.
|
||||
* 64-bit floating-point number (double)
|
||||
* a tuple of several elements, where all elements have the same type (one of the above). An array, whose elements are such tuples, are called multi-channel arrays, as opposite to the single-channel arrays, whose elements are scalar values. The maximum possible number of channels is defined by the ``CV_CN_MAX`` constant (which is not smaller than 32).
|
||||
|
||||
.. todo::
|
||||
Need we extend the above list? Shouldn't we throw away 8-bit signed (schar)?
|
||||
|
||||
For these basic types, the following enumeration is applied::
|
||||
|
||||
enum { CV_8U=0, CV_8S=1, CV_16U=2, CV_16S=3, CV_32S=4, CV_32F=5, CV_64F=6 };
|
||||
@ -194,9 +191,6 @@ Arrays, whose elements are more complex, cannot be constructed or processed usin
|
||||
|
||||
The subset of supported types for each functions has been defined from practical needs. All this information about supported types can be put together into a special table. In different implementations of the standard, the tables may look differently. For example, on embedded platforms the double-precision floating-point type (``CV_64F``) may be unavailable.
|
||||
|
||||
.. todo::
|
||||
Should we include such a table into the standard?
|
||||
Should we specify minimum "must-have" set of supported formats for each functions?
|
||||
|
||||
Error Handling
|
||||
--------------
|
||||
@ -218,6 +212,6 @@ The exception is typically thrown using either the ``CV_Error(errcode, descripti
|
||||
}
|
||||
|
||||
Multi-threading and Re-enterability
|
||||
----------------------------------
|
||||
-----------------------------------
|
||||
|
||||
The current OpenCV implementation is fully re-enterable as should be any alternative implementation targeted for multi-threaded environments. That is, the same function, the same *constant* method of a class instance, or the same *non-constant* method of different class instances can be called from different threads. Also, the same ``cv::Mat`` can be used in different threads because the reference-counting operations use the architecture-specific atomic instructions.
|
||||
The current OpenCV implementation is fully re-enterable. That is, the same function, the same *constant* method of a class instance, or the same *non-constant* method of different class instances can be called from different threads. Also, the same ``cv::Mat`` can be used in different threads because the reference-counting operations use the architecture-specific atomic instructions.
|
||||
|
||||
@ -207,8 +207,6 @@ The functions ``bitwise_and`` compute the per-element bit-wise logical conjuncti
|
||||
|
||||
In case of floating-point arrays, their machine-specific bit representations (usually IEEE754-compliant) are used for the operation. In case of multi-channel arrays, each channel is processed independently.
|
||||
|
||||
See Also: ??
|
||||
|
||||
.. index:: bitwise_not
|
||||
|
||||
.. _bitwise_not_:
|
||||
@ -765,7 +763,7 @@ dft
|
||||
* **DFT_SCALE** Scale the result: divide it by the number of array elements. Normally, it is combined with ``DFT_INVERSE`` . .
|
||||
* **DFT_ROWS** Perform a forward or inverse transform of every individual row of the input matrix. This flag enables you to transform multiple vectors simultaneously and can be used to decrease the overhead (which is sometimes several times larger than the processing itself) to perform 3D and higher-dimensional transforms and so forth.
|
||||
|
||||
* **DFT_COMPLEX_OUTPUT** Perform a forward transformation of 1D or 2D real array. The result, though being a complex array, has complex-conjugate symmetry ( *CCS* ).?? See the description below for details. Such an array can be packed into a real array of the same size as input, which is the fastest option and which is what the function does by default. However, you may wish to get a full complex array (for simpler spectrum analysis, and so on). Pass the flag to enable the function to produce a full-size complex output array.
|
||||
* **DFT_COMPLEX_OUTPUT** Perform a forward transformation of 1D or 2D real array. The result, though being a complex array, has complex-conjugate symmetry (*CCS*, see the function description below for details). Such an array can be packed into a real array of the same size as input, which is the fastest option and which is what the function does by default. However, you may wish to get a full complex array (for simpler spectrum analysis, and so on). Pass the flag to enable the function to produce a full-size complex output array.
|
||||
|
||||
* **DFT_REAL_OUTPUT** Perform an inverse transformation of 1D or 2D complex array. The result is normally a complex array of the same size. However, if the source array has conjugate-complex symmetry (for example, it is a result of forward transformation with ``DFT_COMPLEX_OUTPUT`` flag), the output is a real array. While the function itself does not check whether the input is symmetrical or not, you can pass the flag and then the function will assume the symmetry and produce the real output array. Note that when the input is packed into a real array and inverse transformation is executed, the function treats the input as a packed complex-conjugate symmetrical array. So, the output will also be a real array.
|
||||
|
||||
@ -1868,7 +1866,7 @@ mulSpectrums
|
||||
|
||||
:param dst: Destination array. It has the same size and type as ``src1`` .
|
||||
|
||||
:param flags: The same flags as passed to :func:`dft` . Only the flag ``DFT_ROWS`` is checked for.??
|
||||
:param flags: The operation flags. Currently, the only supported flag is ``DFT_ROWS``, which indicates that each row of ``src1`` and ``src2`` is independent 1D Fourier spectrum.
|
||||
|
||||
:param conj: Optional flag that conjugates the second source array before the multiplication (true) or not (false).
|
||||
|
||||
@ -2679,8 +2677,7 @@ randn
|
||||
|
||||
:param stddev: Standard deviation of the generated random numbers.
|
||||
|
||||
The function ``randn`` fills the matrix ``mtx`` with normally distributed random numbers with the specified mean and standard deviation.
|
||||
?? is applied to the generated numbers (that is, the values are clipped)
|
||||
The function ``randn`` fills the matrix ``mtx`` with normally distributed random numbers with the specified mean and standard deviation. The generated random numbers are clipped to fit the value range of the destination array data type.
|
||||
|
||||
See Also:
|
||||
:func:`RNG`,
|
||||
@ -3445,12 +3442,11 @@ The function ``transform`` performs the matrix transformation of every element o
|
||||
|
||||
(when ``mtx.cols=src.channels()+1`` )
|
||||
|
||||
Every element of the ``N`` -channel array ``src`` is
|
||||
considered as an ``N`` -element vector that is transformed using
|
||||
Every element of the ``N`` -channel array ``src`` is interpreted as ``N`` -element vector that is transformed using
|
||||
the
|
||||
:math:`\texttt{M} \times \texttt{N}` or
|
||||
:math:`\texttt{M} \times \texttt{N+1}` matrix ``mtx`` into??
|
||||
an element of the ``M`` -channel array ``dst`` .
|
||||
:math:`\texttt{M} \times \texttt{N+1}` matrix ``mtx``
|
||||
to ``M``-element vector - the corresponding element of the destination array ``dst`` .
|
||||
|
||||
The function may be used for geometrical transformation of
|
||||
:math:`N` -dimensional
|
||||
|
||||
@ -1,6 +1,8 @@
|
||||
Common Interfaces of Feature Detectors
|
||||
======================================
|
||||
|
||||
.. highlight:: cpp
|
||||
|
||||
Feature detectors in OpenCV have wrappers with common interface that enables to switch easily
|
||||
between different algorithms solving the same problem. All objects that implement keypoint detectors
|
||||
inherit
|
||||
@ -14,7 +16,7 @@ KeyPoint
|
||||
--------
|
||||
.. c:type:: KeyPoint
|
||||
|
||||
Data structure for salient point detectors. ::
|
||||
Data structure for salient point detectors. ::
|
||||
|
||||
class KeyPoint
|
||||
{
|
||||
@ -64,6 +66,8 @@ KeyPoint
|
||||
// reads vector of keypoints from the specified file storage node
|
||||
void read(const FileNode& node, CV_OUT vector<KeyPoint>& keypoints);
|
||||
|
||||
..
|
||||
|
||||
|
||||
.. index:: FeatureDetector
|
||||
|
||||
|
||||
@ -2,6 +2,8 @@
|
||||
features2d. 2D Features Framework
|
||||
*********************************
|
||||
|
||||
.. highlight:: cpp
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
|
||||
@ -1,6 +1,8 @@
|
||||
Data Structures
|
||||
===============
|
||||
|
||||
.. highlight:: cpp
|
||||
|
||||
.. index:: gpu::DevMem2D\_
|
||||
|
||||
gpu::DevMem2D\_
|
||||
@ -286,7 +288,7 @@ gpu::Stream::waitForCompletion
|
||||
----------------------------------
|
||||
.. cpp:function:: void gpu::Stream::waitForCompletion()
|
||||
|
||||
Blocks ?? until all operations in the stream are complete.
|
||||
Blocks the current CPU thread until all operations in the stream are complete.
|
||||
|
||||
.. index:: gpu::StreamAccessor
|
||||
|
||||
@ -348,9 +350,5 @@ gpu::ensureSizeIsEnough
|
||||
|
||||
:param type: Desired matrix type.
|
||||
|
||||
:param m: Destination matrix.
|
||||
|
||||
The following wrapper is also available: ??
|
||||
|
||||
|
||||
:param m: Destination matrix.
|
||||
|
||||
|
||||
@ -7,10 +7,7 @@ Image Processing
|
||||
|
||||
gpu::meanShiftFiltering
|
||||
---------------------------
|
||||
.. cpp:function:: void gpu::meanShiftFiltering(const GpuMat& src, GpuMat& dst,
|
||||
int sp, int sr,
|
||||
TermCriteria criteria = TermCriteria(TermCriteria::MAX_ITER
|
||||
+ TermCriteria::EPS, 5, 1))
|
||||
.. cpp:function:: void gpu::meanShiftFiltering(const GpuMat& src, GpuMat& dst, int sp, int sr,TermCriteria criteria = TermCriteria(TermCriteria::MAX_ITER + TermCriteria::EPS, 5, 1))
|
||||
|
||||
Performs mean-shift filtering for each point of the source image. It maps each point of the source image into another point. As a result, you have a new color and new position of each point.
|
||||
|
||||
@ -22,15 +19,13 @@ gpu::meanShiftFiltering
|
||||
|
||||
:param sr: Color window radius.
|
||||
|
||||
:param criteria: Termination criteria. See :c:class:`TermCriteria`.
|
||||
:param criteria: Termination criteria. See :cpp:class:`TermCriteria`.
|
||||
|
||||
.. index:: gpu::meanShiftProc
|
||||
|
||||
gpu::meanShiftProc
|
||||
----------------------
|
||||
.. cpp:function:: void gpu::meanShiftProc(const GpuMat& src, GpuMat& dstr, GpuMat& dstsp,
|
||||
int sp, int sr, TermCriteria criteria = TermCriteria(TermCriteria::MAX_ITER
|
||||
+ TermCriteria::EPS, 5, 1))
|
||||
.. cpp:function:: void gpu::meanShiftProc(const GpuMat& src, GpuMat& dstr, GpuMat& dstsp, int sp, int sr, TermCriteria criteria = TermCriteria(TermCriteria::MAX_ITER + TermCriteria::EPS, 5, 1))
|
||||
|
||||
Performs a mean-shift procedure and stores information about processed points (their colors and positions) in two images.
|
||||
|
||||
@ -44,7 +39,7 @@ gpu::meanShiftProc
|
||||
|
||||
:param sr: Color window radius.
|
||||
|
||||
:param criteria: Termination criteria. See :c:class:`TermCriteria`.
|
||||
:param criteria: Termination criteria. See :cpp:class:`TermCriteria`.
|
||||
|
||||
See Also:
|
||||
:c:func:`gpu::meanShiftFiltering`
|
||||
@ -67,7 +62,7 @@ gpu::meanShiftSegmentation
|
||||
|
||||
:param minsize: Minimum segment size. Smaller segements are merged.
|
||||
|
||||
:param criteria: Termination criteria. See :c:class:`TermCriteria`.
|
||||
:param criteria: Termination criteria. See :cpp:class:`TermCriteria`.
|
||||
|
||||
.. index:: gpu::integral
|
||||
|
||||
@ -116,15 +111,13 @@ gpu::columnSum
|
||||
|
||||
gpu::cornerHarris
|
||||
---------------------
|
||||
.. cpp:function:: void gpu::cornerHarris(const GpuMat& src, GpuMat& dst,
|
||||
int blockSize, int ksize, double k,
|
||||
int borderType=BORDER_REFLECT101)
|
||||
.. cpp:function:: void gpu::cornerHarris(const GpuMat& src, GpuMat& dst, int blockSize, int ksize, double k, int borderType=BORDER_REFLECT101)
|
||||
|
||||
Computes the Harris cornerness criteria at each image pixel.
|
||||
|
||||
:param src: Source image. Only ``CV_8UC1`` and ``CV_32FC1`` images are supported for now.
|
||||
|
||||
:param dst: Destination image containing cornerness values. The size is the same??. The type is ``CV_32FC1`` .
|
||||
:param dst: Destination image containing cornerness values. It has the same size as ``src`` and ``CV_32FC1`` type.
|
||||
|
||||
:param blockSize: Neighborhood size.
|
||||
|
||||
@ -141,9 +134,7 @@ See Also:
|
||||
|
||||
gpu::cornerMinEigenVal
|
||||
--------------------------
|
||||
.. cpp:function:: void gpu::cornerMinEigenVal(const GpuMat& src, GpuMat& dst,
|
||||
int blockSize, int ksize,
|
||||
int borderType=BORDER_REFLECT101)
|
||||
.. cpp:function:: void gpu::cornerMinEigenVal(const GpuMat& src, GpuMat& dst, int blockSize, int ksize, int borderType=BORDER_REFLECT101)
|
||||
|
||||
Computes the minimum eigen value of 2x2 derivative covariation matrix at each pixel (the cornerness criteria).
|
||||
|
||||
@ -165,8 +156,7 @@ See also: :c:func:`cornerMinEigenVal`
|
||||
|
||||
gpu::mulSpectrums
|
||||
---------------------
|
||||
.. cpp:function:: void gpu::mulSpectrums(const GpuMat& a, const GpuMat& b,
|
||||
GpuMat& c, int flags, bool conjB=false)
|
||||
.. cpp:function:: void gpu::mulSpectrums(const GpuMat& a, const GpuMat& b, GpuMat& c, int flags, bool conjB=false)
|
||||
|
||||
Performs a per-element multiplication of two Fourier spectrums.
|
||||
|
||||
@ -189,8 +179,7 @@ See Also:
|
||||
|
||||
gpu::mulAndScaleSpectrums
|
||||
-----------------------------
|
||||
.. cpp:function:: void gpu::mulAndScaleSpectrums(const GpuMat& a, const GpuMat& b,
|
||||
GpuMat& c, int flags, float scale, bool conjB=false)
|
||||
.. cpp:function:: void gpu::mulAndScaleSpectrums(const GpuMat& a, const GpuMat& b, GpuMat& c, int flags, float scale, bool conjB=false)
|
||||
|
||||
Performs a per-element multiplication of two Fourier spectrums and scales the result.
|
||||
|
||||
@ -254,11 +243,9 @@ See Also:
|
||||
|
||||
gpu::convolve
|
||||
-----------------
|
||||
.. cpp:function:: void gpu::convolve(const GpuMat& image, const GpuMat& templ, GpuMat& result,
|
||||
bool ccorr=false)
|
||||
.. cpp:function:: void gpu::convolve(const GpuMat& image, const GpuMat& templ, GpuMat& result, bool ccorr=false)
|
||||
|
||||
.. cpp:function:: void gpu::convolve(const GpuMat& image, const GpuMat& templ, GpuMat& result,
|
||||
bool ccorr, ConvolveBuf& buf)
|
||||
.. cpp:function:: void gpu::convolve(const GpuMat& image, const GpuMat& templ, GpuMat& result, bool ccorr, ConvolveBuf& buf)
|
||||
|
||||
Computes a convolution (or cross-correlation) of two images.
|
||||
|
||||
@ -314,8 +301,7 @@ gpu::ConvolveBuf::ConvolveBuf
|
||||
|
||||
gpu::matchTemplate
|
||||
----------------------
|
||||
.. cpp:function:: void gpu::matchTemplate(const GpuMat& image, const GpuMat& templ,
|
||||
GpuMat& result, int method)
|
||||
.. cpp:function:: void gpu::matchTemplate(const GpuMat& image, const GpuMat& templ, GpuMat& result, int method)
|
||||
|
||||
Computes a proximity map for a raster template and an image where the template is searched for.
|
||||
|
||||
|
||||
@ -1,6 +1,8 @@
|
||||
Feature Detection
|
||||
=================
|
||||
|
||||
.. highlight:: cpp
|
||||
|
||||
.. index:: Canny
|
||||
|
||||
.. _Canny:
|
||||
|
||||
@ -1,5 +1,7 @@
|
||||
.. _ImageFiltering:
|
||||
|
||||
.. highlight:: cpp
|
||||
|
||||
Image Filtering
|
||||
===============
|
||||
|
||||
@ -881,10 +883,7 @@ The function does actually compute correlation, not the convolution:
|
||||
That is, the kernel is not mirrored around the anchor point. If you need a real convolution, flip the kernel using
|
||||
:func:`flip` and set the new anchor to ``(kernel.cols - anchor.x - 1, kernel.rows - anchor.y - 1)`` .
|
||||
|
||||
The function uses the
|
||||
??-based algorithm in case of sufficiently large kernels (~
|
||||
:math:`11\times11` ) and the direct algorithm (that uses the engine retrieved by
|
||||
:func:`createLinearFilter` ) for small kernels.
|
||||
The function uses the DFT-based algorithm in case of sufficiently large kernels (~``11 x 11`` or larger) and the direct algorithm (that uses the engine retrieved by :func:`createLinearFilter` ) for small kernels.
|
||||
|
||||
See Also:
|
||||
:func:`sepFilter2D`,
|
||||
@ -971,10 +970,12 @@ The function computes and returns the
|
||||
where
|
||||
:math:`i=0..\texttt{ksize}-1` and
|
||||
:math:`\alpha` is the scale factor chosen so that
|
||||
:math:`\sum_i G_i=1` . Two of such generated kernels can be passed to
|
||||
:math:`\sum_i G_i=1`.
|
||||
|
||||
Two of such generated kernels can be passed to
|
||||
:func:`sepFilter2D` or to
|
||||
:func:`createSeparableLinearFilter` . These functions?? automatically recognize smoothing kernels and handle them accordingly. You may also use the higher-level
|
||||
:func:`GaussianBlur` .
|
||||
:func:`createSeparableLinearFilter`. Those functions automatically recognize smoothing kernels (i.e. symmetrical kernel with sum of weights = 1) and handle them accordingly. You may also use the higher-level
|
||||
:func:`GaussianBlur`.
|
||||
|
||||
See Also:
|
||||
:func:`sepFilter2D`,
|
||||
|
||||
@ -1,6 +1,8 @@
|
||||
Geometric Image Transformations
|
||||
===============================
|
||||
|
||||
.. highlight:: cpp
|
||||
|
||||
The functions in this section perform various geometrical transformations of 2D images. They do not change the image content but deform the pixel grid, and map this deformed grid to the destination image. In fact, to avoid sampling artifacts, the mapping is done in the reverse order, from destination to the source. That is, for each pixel
|
||||
:math:`(x, y)` of the destination image, the functions compute coordinates of the corresponding "donor" pixel in the source image and copy the pixel value:
|
||||
|
||||
@ -323,7 +325,7 @@ resize
|
||||
|
||||
* **INTER_LINEAR** - a bilinear interpolation (used by default)
|
||||
|
||||
* **INTER_AREA** - resampling using pixel area relation. It may be a preferred method for image decimation, as it gives freer?? results. But when the image is zoomed, it is similar to the ``INTER_NEAREST`` method.
|
||||
* **INTER_AREA** - resampling using pixel area relation. It may be a preferred method for image decimation, as it gives moire-free results. But when the image is zoomed, it is similar to the ``INTER_NEAREST`` method.
|
||||
|
||||
* **INTER_CUBIC** - a bicubic interpolation over 4x4 pixel neighborhood
|
||||
|
||||
|
||||
@ -1,6 +1,8 @@
|
||||
Histograms
|
||||
==========
|
||||
|
||||
.. highlight:: cpp
|
||||
|
||||
.. index:: calcHist
|
||||
|
||||
.. _calcHist:
|
||||
|
||||
@ -1,6 +1,8 @@
|
||||
Miscellaneous Image Transformations
|
||||
===================================
|
||||
|
||||
.. highlight:: cpp
|
||||
|
||||
.. index:: adaptiveThreshold
|
||||
|
||||
.. _adaptiveThreshold:
|
||||
|
||||
@ -1,6 +1,8 @@
|
||||
Motion Analysis and Object Tracking
|
||||
===================================
|
||||
|
||||
.. highlight:: cpp
|
||||
|
||||
.. index:: accumulate
|
||||
|
||||
accumulate
|
||||
|
||||
@ -1,11 +1,13 @@
|
||||
Object Detection
|
||||
================
|
||||
|
||||
.. highlight:: cpp
|
||||
|
||||
.. index:: matchTemplate
|
||||
|
||||
matchTemplate
|
||||
-----------------
|
||||
.. c:function:: void matchTemplate( const Mat\& image, const Mat\& templ, Mat\& result, int method )
|
||||
.. c:function:: void matchTemplate( const Mat& image, const Mat& temp, Mat& result, int method )
|
||||
|
||||
Compares a template against overlapped image regions.
|
||||
|
||||
|
||||
@ -1,6 +1,8 @@
|
||||
Structural Analysis and Shape Descriptors
|
||||
=========================================
|
||||
|
||||
.. highlight:: cpp
|
||||
|
||||
.. index:: moments
|
||||
|
||||
moments
|
||||
|
||||
Loading…
Reference in New Issue
Block a user