\cvarg{colorModel}{Ignored by OpenCV. The OpenCV function \cross{CvtColor} requires the source and destination color spaces as parameters.}
\cvarg{channelSeq}{Ignored by OpenCV}
\cvarg{dataOrder}{0 = \texttt{IPL\_DATA\_ORDER\_PIXEL} - interleaved color channels, 1 - separate color channels. \cross{CreateImage} only creates images with interleaved channels. For example, the usual layout of a color image is: $ b_{00} g_{00} r_{00} b_{10} g_{10} r_{10} ...$}
\cvarg{align}{Alignment of image rows (4 or 8). OpenCV ignores this and uses widthStep instead.}
\cvarg{width}{Image width in pixels}
\cvarg{height}{Image height in pixels}
\cvarg{roi}{Region Of Interest (ROI). If not NULL, only this image region will be processed.}
\cvarg{maskROI}{Must be NULL in OpenCV}
\cvarg{imageId}{Must be NULL in OpenCV}
\cvarg{tileInfo}{Must be NULL in OpenCV}
\cvarg{imageSize}{Image data size in bytes. For interleaved data, this equals $\texttt{image->height}\cdot\texttt{image->widthStep}$}
\cvarg{imageData}{A pointer to the aligned image data}
\cvarg{widthStep}{The size of an aligned image row, in bytes}
\cvarg{BorderMode}{Border completion mode, ignored by OpenCV}
\cvarg{BorderConst}{Border completion mode, ignored by OpenCV}
\cvarg{imageDataOrigin}{A pointer to the origin of the image data (not necessarily aligned). This is used for image deallocation.}
\end{description}
The \cross{IplImage} structure was inherited from the Intel Image Processing Library, in which the format is native. OpenCV only supports a subset of possible \cross{IplImage} formats, as outlined in the parameter list above.
In addition to the above restrictions, OpenCV handles ROIs differently. OpenCV functions require that the image size or ROI size of all source and destination images match exactly. On the other hand, the Intel Image Processing Library processes the area of intersection between the source and destination images (or ROIs), allowing them to vary independently.
\fi
\ifPy
The \cross{IplImage} object was inherited from the Intel Image Processing
Library, in which the format is native. OpenCV only supports a subset
of possible \cross{IplImage} formats.
\begin{description}
\cvarg{nChannels}{Number of channels, int.}
\cvarg{width}{Image width in pixels}
\cvarg{height}{Image height in pixels}
\cvarg{depth}{Pixel depth in bits. The supported depths are:
\cvarg{tostring() -> str}{Returns the contents of the CvMatND as a single string.}
\end{description}
\fi
\label{CvArr}\cvclass{CvArr}
Arbitrary array
\ifC
\begin{lstlisting}
typedef void CvArr;
\end{lstlisting}
The metatype \texttt{CvArr} is used \textit{only} as a function parameter to specify that the function accepts arrays of multiple types, such as IplImage*, CvMat* or even CvSeq* sometimes. The particular array type is determined at runtime by analyzing the first 4 bytes of the header.
\fi
\ifPy
\texttt{CvArr} is used \textit{only} as a function parameter to specify that the parameter can be:
\begin{itemize}
\item{an \cross{IplImage}}
\item{a \cross{CvMat}}
\item{any other type that exports the \href{http://docs.scipy.org/doc/numpy/reference/arrays.interface.html}{array interface}}
The template class \texttt{DataType} is descriptive class for OpenCV primitive data types and other types that comply with the following definition. A primitive OpenCV data type is one of \texttt{unsigned char, bool, signed char, unsigned short, signed short, int, float, double} or a tuple of values of one of these types, where all the values in the tuple have the same type. If you are familiar with OpenCV \cross{CvMat}'s type notation, CV\_8U ... CV\_32FC3, CV\_64FC2 etc., then a primitive type can be defined as a type for which you can give a unique identifier in a form \texttt{CV\_<bit-depth>{U|S|F}C<number\_of\_channels>}. A universal OpenCV structure able to store a single instance of such primitive data type is \cross{Vec}. Multiple instances of such a type can be stored to a \texttt{std::vector}, \texttt{Mat}, \texttt{Mat\_}, \texttt{SparseMat}, \texttt{SparseMat\_} or any other container that is able to store \cross{Vec} instances.
The class \texttt{DataType} is basically used to provide some description of such primitive data types without adding any fields or methods to the corresponding classes (and it is actually impossible to add anything to primitive C/C++ data types). This technique is known in C++ as class traits. It's not \texttt{DataType} itself that is used, but its specialized versions, such as:
that is, such traits are used to tell OpenCV which data type you are working with, even if such a type is not native to OpenCV (the matrix \texttt{B} intialization above compiles because OpenCV defines the proper specialized template class \texttt{DataType<complex<\_Tp> >}). Also, this mechanism is useful (and used in OpenCV this way) for generic algorithms implementations.
// computes dot-product using double-precision arithmetics
double ddot(const Point_& pt) const;
// returns true if the point is inside the rectangle "r".
bool inside(const Rect_<_Tp>& r) const;
_Tp x, y;
};
\end{lstlisting}
The class represents a 2D point, specified by its coordinates $x$ and $y$.
Instance of the class is interchangeable with C structures \texttt{CvPoint} and \texttt{CvPoint2D32f}. There is also cast operator to convert point coordinates to the specified type. The conversion from floating-point coordinates to integer coordinates is done by rounding; in general case the conversion uses \hyperref[saturatecast]{saturate\_cast} operation on each of the coordinates. Besides the class members listed in the declaration above, the following operations on points are implemented:
\begin{lstlisting}
pt1 = pt2 + pt3;
pt1 = pt2 - pt3;
pt1 = pt2 * a;
pt1 = a * pt2;
pt1 += pt2;
pt1 -= pt2;
pt1 *= a;
double value = norm(pt); // L2 norm
pt1 == pt2;
pt1 != pt2;
\end{lstlisting}
For user convenience, the following type aliases are defined:
The class represents a 3D point, specified by its coordinates $x$, $y$ and $z$.
Instance of the class is interchangeable with C structure \texttt{CvPoint2D32f}. Similarly to \texttt{Point\_}, the 3D points' coordinates can be converted to another type, and the vector arithmetic and comparison operations are also supported.
The following type aliases are available:
\begin{lstlisting}
typedef Point3_<int> Point3i;
typedef Point3_<float> Point3f;
typedef Point3_<double> Point3d;
\end{lstlisting}
\subsection{Size\_}
Template class for specfying image or rectangle size.
\begin{lstlisting}
template<typename _Tp> class Size_
{
public:
typedef _Tp value_type;
Size_();
Size_(_Tp _width, _Tp _height);
Size_(const Size_& sz);
Size_(const CvSize& sz);
Size_(const CvSize2D32f& sz);
Size_(const Point_<_Tp>& pt);
Size_& operator = (const Size_& sz);
_Tp area() const;
operator Size_<int>() const;
operator Size_<float>() const;
operator Size_<double>() const;
operator CvSize() const;
operator CvSize2D32f() const;
_Tp width, height;
};
\end{lstlisting}
The class \texttt{Size\_} is similar to \texttt{Point\_}, except that the two members are called \texttt{width} and \texttt{height} instead of \texttt{x} and \texttt{y}. The structure can be converted to and from the old OpenCV structures \cross{CvSize} and \cross{CvSize2D32f}. The same set of arithmetic and comparison operations as for \texttt{Point\_} is available.
The rectangle is described by the coordinates of the top-left corner (which is the default interpretation of \texttt{Rect\_::x} and \texttt{Rect\_::y} in OpenCV; though, in your algorithms you may count \texttt{x} and \texttt{y} from the bottom-left corner), the rectangle width and height.
Another assumption OpenCV usually makes is that the top and left boundary of the rectangle are inclusive, while the right and bottom boundaries are not, for example, the method \texttt{Rect\_::contains} returns true if
\[
x \leq pt.x < x+width,
y \leq pt.y < y+height
\]
And virtually every loop over an image \cross{ROI} in OpenCV (where ROI is specified by \texttt{Rect\_<int>}) is implemented as:
\begin{lstlisting}
for(int y = roi.y; y < roi.y + rect.height; y++)
for(int x = roi.x; x < roi.x + rect.width; x++)
{
// ...
}
\end{lstlisting}
In addition to the class members, the following operations on rectangles are implemented:
\begin{itemize}
\item$\texttt{rect}=\texttt{rect}\pm\texttt{point}$ (shifting rectangle by a certain offset)
\item$\texttt{rect}=\texttt{rect}\pm\texttt{size}$ (expanding or shrinking rectangle by a certain amount)
\item\texttt{rect += point, rect -= point, rect += size, rect -= size} (augmenting operations)
The class represents small matrices, which type and size are known at compile time. If you need more flexible type, use \cross{Mat}. The elements of a matrix \texttt{M} are accessible using \texttt{M(i,j)} notation, and most of the common matrix operations (see also \cross{MatrixExpressions}) are available. If you need to do some operation on \texttt{Matx} that is not implemented, it is easy to convert the matrix to \cross{Mat} and backwards.
\texttt{Vec} is a partial case of \texttt{Matx}. It is possible to convert \texttt{Vec<T,2>} to/from \texttt{Point\_}, \texttt{Vec<T,3>} to/from \texttt{Point3\_}, and \texttt{Vec<T,4>} to \cross{CvScalar} or \cross{Scalar}. The elements of \texttt{Vec} are accessed using \texttt{operator[]}. All the expected vector operations are implemented too:
\begin{itemize}
\item$\texttt{v1}=\texttt{v2}\pm\texttt{v3}$, $\texttt{v1}=\texttt{v2}*\alpha$, $\texttt{v1}=\alpha*\texttt{v2}$ (plus the corresponding augmenting operations; note that these operations apply \hyperref[saturatecast]{saturate\_cast.3C.3E} to the each computed vector component)
\item\texttt{v1 == v2, v1 != v2}
\item\texttt{norm(v1)} ($L_2$-norm)
\end{itemize}
The class \texttt{Vec} is commonly used to describe pixel types of multi-channel arrays, see \texttt{Mat\_} description.
template<typename T2> void convertTo(T2* buf, int channels, int unroll_to=0) const;
};
typedef Scalar_<double> Scalar;
\end{lstlisting}
The template class \texttt{Scalar\_} and it's double-precision instantiation \texttt{Scalar} represent 4-element vector. Being derived from \texttt{Vec<\_Tp, 4>}, they can be used as typical 4-element vectors, but in addition they can be converted to/from \texttt{CvScalar}. The type \texttt{Scalar} is widely used in OpenCV for passing pixel values and it is a drop-in replacement for \cross{CvScalar} that was used for the same purpose in the earlier versions of OpenCV.
\subsection{Range}\label{Range}
Specifies a continuous subsequence (a.k.a. slice) of a sequence.
\begin{lstlisting}
class Range
{
public:
Range();
Range(int _start, int _end);
Range(const CvSlice& slice);
int size() const;
bool empty() const;
static Range all();
operator CvSlice() const;
int start, end;
};
\end{lstlisting}
The class is used to specify a row or column span in a matrix (\cross{Mat}), and for many other purposes. \texttt{Range(a,b)} is basically the same as \texttt{a:b} in Matlab or \texttt{a..b} in Python. As in Python, \texttt{start} is inclusive left boundary of the range, and \texttt{end} is exclusive right boundary of the range. Such a half-opened interval is usually denoted as $[start,end)$.
The static method \texttt{Range::all()} returns some special variable that means "the whole sequence" or "the whole range", just like "\texttt{:}" in Matlab or "\texttt{...}" in Python. All the methods and functions in OpenCV that take \texttt{Range} support this special \texttt{Range::all()} value, but of course, in the case of your own custom processing you will probably have to check and handle it explicitly:
\begin{lstlisting}
void my_function(..., const Range& r, ....)
{
if(r == Range::all()) {
// process all the data
}
else {
// process [r.start, r.end)
}
}
\end{lstlisting}
\subsection{Ptr}\label{Ptr}
A template class for smart reference-counting pointers
// provide access to the object fields and methods
_Tp* operator -> ();
const _Tp* operator -> () const;
// return the underlying object pointer;
// thanks to the methods, the Ptr<_Tp> can be
// used instead of _Tp*
operator _Tp* ();
operator const _Tp*() const;
protected:
// the encapsulated object pointer
_Tp* obj;
// the associated reference counter
int* refcount;
};
\end{lstlisting}
The class \texttt{Ptr<\_Tp>} is a template class that wraps pointers of the corresponding type. It is similar to \texttt{shared\_ptr} that is a part of Boost library (\url{http://www.boost.org/doc/libs/1_40_0/libs/smart_ptr/shared_ptr.htm}) and also a part of the
By using this class you can get the following capabilities:
\begin{itemize}
\item default constructor, copy constructor and assignment operator for an arbitrary C++ class or a C structure. For some objects, like files, windows, mutexes, sockets etc, copy constructor or assignment operator are difficult to define. For some other objects, like complex classifiers in OpenCV, copy constructors are absent and not easy to implement. Finally, some of complex OpenCV and your own data structures may have been written in C. However, copy constructors and default constructors can simplify programming a lot; besides, they are often required (e.g. by STL containers). By wrapping a pointer to such a complex object \texttt{TObj} to \texttt{Ptr<TObj>} you will automatically get all of the necessary constructors and the assignment operator.
\item all the above-mentioned operations running very fast, regardless of the data size, i.e. as "O(1)" operations. Indeed, while some structures, like \texttt{std::vector} provide a copy constructor and an assignment operator, the operations may take considerable time if the data structures are big. But if the structures are put into \texttt{Ptr<>}, the overhead becomes small and independent of the data size.
\item automatic destruction, even for C structures. See the example below with \texttt{FILE*}.
\item heterogeneous collections of objects. The standard STL and most other C++ and OpenCV containers can only store objects of the same type and the same size. The classical solution to store objects of different types in the same container is to store pointers to the base class \texttt{base\_class\_t*} instead, but when you loose the automatic memory management. Again, by using \texttt{Ptr<base\_class\_t>()} instead of the raw pointers, you can solve the problem.
\end{itemize}
The class \texttt{Ptr} treats the wrapped object as a black box, the reference counter is allocated and managed separately. The only thing the pointer class needs to know about the object is how to deallocate it. This knowledge is incapsulated in \texttt{Ptr::delete\_obj()} method, which is called when the reference counter becomes 0. If the object is a C++ class instance, no additional coding is needed, because the default implementation of this method calls \texttt{delete obj;}.
However, if the object is deallocated in a different way, then the specialized method should be created. For example, if you want to wrap \texttt{FILE}, the \texttt{delete\_obj} may be implemented as following:
\begin{lstlisting}
template<> inline void Ptr<FILE>::delete_obj()
{
fclose(obj); // no need to clear the pointer afterwards,
// it is done externally.
}
...
// now use it:
Ptr<FILE> f(fopen("myfile.txt", "r"));
if(f.empty())
throw ...;
fprintf(f, ....);
...
// the file will be closed automatically by the Ptr<FILE> destructor.
\end{lstlisting}
\textbf{Note}: The reference increment/decrement operations are implemented as atomic operations, and therefore it is normally safe to use the classes in multi-threaded applications. The same is true for \cross{Mat} and other C++ OpenCV classes that operate on the reference counters.
The class \texttt{Mat} represents an n-dimensional dense numerical single-channel or multi-channel array. It can be used to store real or complex-valued vectors and matrices, grayscale or color images, voxel volumes, vector fields, point clouds, tensors, histograms (though, very high-dimensional histograms may be better stored in a \texttt{SparseMat}). The data layout of array $M$ is defined by the array \texttt{M.step[]}, so that the address of element $(i_0,...,i_{M.dims-1})$, where $0\leq i_k<M.size[k]$ is computed as:
Note that \texttt{M.step[i] >= M.step[i+1]} (in fact, \texttt{M.step[i] >= M.step[i+1]*M.size[i+1]}), that is, 2-dimensional matrices are stored row-by-row, 3-dimensional matrices are stored plane-by-plane etc. \texttt{M.step[M.dims-1]} is minimal and always equal to the element size \texttt{M.elemSize()}.
That is, the data layout in \texttt{Mat} is fully compatible with \texttt{CvMat}, \texttt{IplImage} and \texttt{CvMatND} types from OpenCV 1.x, as well as with majority of dense array types from the standard toolkits and SDKs, such as Numpy (ndarray), Win32 (independent device bitmaps) etc, i.e. any other array that uses "steps", a.k.a. "strides", to compute position of a pixel. Because of such compatibility, it is possible to make a \texttt{Mat} header for user-allocated data and process it in-place using OpenCV functions.
\item similarly to above, you can create a multi-dimensional array:
\begin{lstlisting}
// create 100x100x100 8-bit array
int sz[] = {100, 100, 100};
cv::Mat bigCube(3, sz, CV_8U, Scalar::all(0));
\end{lstlisting}
note that it is pass number of dimensions =1 to the \texttt{Mat} constructor, but the created array will be 2-dimensional, with the number of columns set to 1. That's why \texttt{Mat::dims} is always >= 2 (can also be 0 when the array is empty)
here we first call constructor of \texttt{Mat\_} class (that we describe further) with the proper parameters, and then we just put \texttt{<<} operator followed by comma-separated values that can be constants, variables, expressions etc. Also, note the extra parentheses that are needed to avoid compiler errors.
Once array is created, it will be automatically managed by using reference-counting mechanism (unless the array header is built on top of user-allocated data, in which case you should handle the data by yourself).
The array data will be deallocated when no one points to it; if you want to release the data pointed by a array header before the array destructor is called, use \texttt{Mat::release()}.
The next important thing to learn about the array class is element access. Earlier it was shown how to compute address of each array element. Normally, it's not needed to use the formula directly in your code. If you know the array element type (which can be retrieved using the method \texttt{Mat::type()}), you can access element $M_{ij}$ of 2-dimensional array as:
If you need to process a whole row of a 2d array, the most efficient way is to get the pointer to the row first, and then just use plain C operator \texttt{[]}:
Some operations, like the above one, do not actually depend on the array shape, they just process elements of an array one by one (or elements from multiple arrays that have the same coordinates, e.g. array addition). Such operations are called element-wise and it makes sense to check whether all the input/output arrays are continuous, i.e. have no gaps in the end of each row, and if yes, process them as a single long row:
// compute sum of positive matrix elements, optimized variant
double sum=0;
int cols = M.cols, rows = M.rows;
if(M.isContinuous())
{
cols *= rows;
rows = 1;
}
for(int i = 0; i < rows; i++)
{
const double* Mi = M.ptr<double>(i);
for(int j = 0; j < cols; j++)
sum += std::max(Mi[j], 0.);
}
\end{lstlisting}
in the case of continuous matrix the outer loop body will be executed just once, so the overhead will be smaller, which will be especially noticeable in the case of small matrices.
Finally, there are STL-style iterators that are smart enough to skip gaps between successive rows:
\begin{lstlisting}
// compute sum of positive matrix elements, iterator-based variant
double sum=0;
MatConstIterator_<double> it = M.begin<double>(), it_end = M.end<double>();
for(; it != it_end; ++it)
sum += std::max(*it, 0.);
\end{lstlisting}
The matrix iterators are random-access iterators, so they can be passed to any STL algorithm, including \texttt{std::sort()}.
\subsection{Matrix Expressions}
This is a list of implemented matrix operations that can be combined in arbitrary complex expressions
(here \emph{A}, \emph{B} stand for matrices (\texttt{Mat}), \emph{s} for a scalar (\texttt{Scalar}),
matrix constructors and operators that extract sub-matrices (see \cross{Mat} description).
\item\verb"Mat_<destination_type>()" constructors to cast the result to the proper type.
\end{itemize}
Note, however, that comma-separated initializers and probably some other operations may require additional explicit \texttt{Mat()} or \verb"Mat_<T>()" constuctor calls to resolve possible ambiguity.
Below is the formal description of the \texttt{Mat} methods.
\cvarg{size}{The 2D array size: \texttt{Size(cols, rows)}. Note that in the \texttt{Size()} constructor the number of rows and the number of columns go in the reverse order.}
\cvarg{sizes}{The array of integers, specifying the n-dimensional array shape}
\cvarg{type}{The array type, use \texttt{CV\_8UC1, ..., CV\_64FC4} to create 1-4 channel matrices, or \texttt{CV\_8UC(n), ..., CV\_64FC(n)} to create multi-channel (up to \texttt{CV\_MAX\_CN} channels) matrices}
\cvarg{s}{The optional value to initialize each matrix element with. To set all the matrix elements to the particular value after the construction, use the assignment operator \texttt{Mat::operator=(const Scalar\& value)}.}
\cvarg{data}{Pointer to the user data. Matrix constructors that take \texttt{data} and \texttt{step} parameters do not allocate matrix data. Instead, they just initialize the matrix header that points to the specified data, i.e. no data is copied. This operation is very efficient and can be used to process external data using OpenCV functions. The external data is not automatically deallocated, user should take care of it.}
\cvarg{step}{The \texttt{data} buddy. This optional parameter specifies the number of bytes that each matrix row occupies. The value should include the padding bytes in the end of each row, if any. If the parameter is missing (set to \texttt{cv::AUTO\_STEP}), no padding is assumed and the actual step is calculated as \texttt{cols*elemSize()}, see \cross{Mat::elemSize}().}
\cvarg{steps}{The array of \texttt{ndims-1} steps in the case of multi-dimensional array (the last step is always set to the element size). If not specified, the matrix is assumed to be continuous.}
\cvarg{m}{The array that (in whole, a partly) is assigned to the constructed matrix. No data is copied by these constructors. Instead, the header pointing to \texttt{m} data, or its sub-array, is constructed and the associated with it reference counter, if any, is incremented. That is, when you modify the matrix formed using such a constructor, you will also modify the corresponding elements of \texttt{m}. If you want to have an independent copy of the sub-array, use \texttt{Mat::clone()}.}
\cvarg{img}{Pointer to the old-style \texttt{IplImage} image structure. By default, the data is shared between the original image and the new matrix, but when \texttt{copyData} is set, the full copy of the image data is created.}
\cvarg{vec}{STL vector, which elements will form the matrix. The matrix will have a single column and the number of rows equal to the number of vector elements. Type of the matrix will match the type of vector elements. The constructor can handle arbitrary types, for which there is properly declared \cross{DataType}, i.e. the vector elements must be primitive numbers or uni-type numerical tuples of numbers. Mixed-type structures are not supported, of course. Note that the corresponding constructor is explicit, meaning that STL vectors are not automatically converted to \texttt{Mat} instances, you should write \texttt{Mat(vec)} explicitly. Another obvious note: unless you copied the data into the matrix (\texttt{copyData=true}), no new elements should be added to the vector, because it can potentially yield vector data reallocation, and thus the matrix data pointer will become invalid.}
\cvarg{copyData}{Specifies, whether the underlying data of the STL vector, or the old-style \texttt{CvMat} or \texttt{IplImage} should be copied to (true) or shared with (false) the newly constructed matrix. When the data is copied, the allocated buffer will be managed using \texttt{Mat}'s reference counting mechanism. While when the data is shared, the reference counter will be NULL, and you should not deallocate the data until the matrix is not destructed.}
\cvarg{rowRange}{The range of the \texttt{m}'s rows to take. As usual, the range start is inclusive and the range end is exclusive. Use \texttt{Range::all()} to take all the rows.}
\cvarg{colRange}{The range of the \texttt{m}'s columns to take. Use \texttt{Range::all()} to take all the columns.}
\cvarg{expr}{Matrix expression. See \cross{Matrix Expressions}.}
\end{description}
These are various constructors that form a matrix. As noticed in the
\hyperref{AutomaticMemoryManagement2}{introduction}, 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 dereferenced, or be allocated with \cross{Mat::create}.
\cvarg{m}{The assigned, right-hand-side matrix. Matrix assignment is O(1) operation, that is, no data is copied. Instead, the data is shared and the reference counter, if any, is incremented. Before assigning new data, the old data is dereferenced via \cross{Mat::release}.}
\cvarg{expr}{The assigned matrix expression object. As opposite to the first form of assignment operation, the second form can reuse already allocated matrix if it has the right size and type to fit the matrix expression result. It is automatically handled by the real function that the matrix expressions is expanded to. For example, \texttt{C=A+B} is expanded to \texttt{cv::add(A, B, C)}, and \cvCppCross{add} will take care of automatic \texttt{C} reallocation.}
\cvarg{s}{The scalar, assigned to each matrix element. The matrix size or type is not changed.}
\end{description}
These are the available assignment operators, and they all are very different, so, please, look at the operator parameters description.
The cast operator should not be called explicitly. It is used internally by the \cross{Matrix Expressions} engine.
\cvCppFunc{Mat::row}
Makes a matrix header for the specified matrix row
\cvdefCpp{
Mat Mat::row(int i) const;
}
\begin{description}
\cvarg{i}{the 0-based row index}
\end{description}
The method makes a new header for the specified matrix row and returns it. This is O(1) operation, regardless of the matrix size. The underlying data of the new matrix will be shared with the original matrix. Here is the example of one of the classical basic matrix processing operations, axpy, used by LU and many other algorithms:
\begin{lstlisting}
inline void matrix_axpy(Mat& A, int i, int j, double alpha)
{
A.row(i) += A.row(j)*alpha;
}
\end{lstlisting}
\textbf{Important note}. In the current implementation the following code will not work as expected:
\begin{lstlisting}
Mat A;
...
A.row(i) = A.row(j); // will not work
\end{lstlisting}
This is because \texttt{A.row(i)} forms a temporary header, which is further assigned another header. Remember, each of these operations is O(1), i.e. no data is copied. Thus, the above assignment will have absolutely no effect, while you may have expected j-th row being copied to i-th row. To achieve that, you should either turn this simple assignment into an expression, or use \cross{Mat::copyTo} method:
\begin{lstlisting}
Mat A;
...
// works, but looks a bit obscure.
A.row(i) = A.row(j) + 0;
// this is a bit longer, but the recommended method.
Mat Ai = A.row(i); M.row(j).copyTo(Ai);
\end{lstlisting}
\cvCppFunc{Mat::col}
Makes a matrix header for the specified matrix column
\cvdefCpp{
Mat Mat::col(int j) const;
}
\begin{description}
\cvarg{j}{the 0-based column index}
\end{description}
The method makes a new header for the specified matrix column and returns it. This is O(1) operation, regardless of the matrix size. The underlying data of the new matrix will be shared with the original matrix. See also \cross{Mat::row} description.
\cvCppFunc{Mat::rowRange}
Makes a matrix header for the specified row span
\cvdefCpp{
Mat Mat::rowRange(int startrow, int endrow) const;\newline
Mat Mat::rowRange(const Range\& r) const;
}
\begin{description}
\cvarg{startrow}{the 0-based start index of the row span}
\cvarg{endrow}{the 0-based ending index of the row span}
\cvarg{r}{The \cvCppCross{Range} structure containing both the start and the end indices}
\end{description}
The method makes a new header for the specified row span of the matrix. Similarly to \cvCppCross{Mat::row} and \cvCppCross{Mat::col}, this is O(1) operation.
\cvCppFunc{Mat::colRange}
Makes a matrix header for the specified row span
\cvdefCpp{
Mat Mat::colRange(int startcol, int endcol) const;\newline
Mat Mat::colRange(const Range\& r) const;
}
\begin{description}
\cvarg{startcol}{the 0-based start index of the column span}
\cvarg{endcol}{the 0-based ending index of the column span}
\cvarg{r}{The \cvCppCross{Range} structure containing both the start and the end indices}
\end{description}
The method makes a new header for the specified column span of the matrix. Similarly to \cvCppCross{Mat::row} and \cvCppCross{Mat::col}, this is O(1) operation.
\cvCppFunc{Mat::diag}
Extracts diagonal from a matrix, or creates a diagonal matrix.
\cvdefCpp{
Mat Mat::diag(int d) const;
static Mat Mat::diag(const Mat\& matD);
}
\begin{description}
\cvarg{d}{index of the diagonal, with the following meaning:}
\begin{description}
\cvarg{d=0}{the main diagonal}
\cvarg{d>0}{a diagonal from the lower half, e.g. \texttt{d=1} means the diagonal immediately below the main one}
\cvarg{d<0}{a diagonal from the upper half, e.g. \texttt{d=1} means the diagonal immediately above the main one}
\end{description}
\cvarg{matD}{single-column matrix that will form the diagonal matrix.}
\end{description}
The method makes a new header for the specified matrix diagonal. The new matrix will be represented as a single-column matrix. Similarly to \cvCppCross{Mat::row} and \cvCppCross{Mat::col}, this is O(1) operation.
The method creates full copy of the array. The original \texttt{step[]} are not taken into the account. That is, the array copy will be a continuous array occupying \texttt{total()*elemSize()} bytes.
void Mat::copyTo( Mat\& m, const Mat\& mask ) const;
}
\begin{description}
\cvarg{m}{The destination matrix. If it does not have a proper size or type before the operation, it will be reallocated}
\cvarg{mask}{The operation mask. Its non-zero elements indicate, which matrix elements need to be copied}
\end{description}
The method copies the matrix data to another matrix. Before copying the data, the method invokes
\begin{lstlisting}
m.create(this->size(), this->type);
\end{lstlisting}
so that the destination matrix is reallocated if needed. While \texttt{m.copyTo(m);} will work as expected, i.e. will have no effect, the function does not handle the case of a partial overlap between the source and the destination matrices.
When the operation mask is specified, and the \texttt{Mat::create} call shown above reallocated the matrix, the newly allocated matrix is initialized with all 0's before copying the data.
void Mat::convertTo( Mat\& m, int rtype, double alpha=1, double beta=0 ) const;
}
\begin{description}
\cvarg{m}{The destination matrix. If it does not have a proper size or type before the operation, it will be reallocated}
\cvarg{rtype}{The desired destination matrix type, or rather, the depth (since the number of channels will be the same with the source one). If \texttt{rtype} is negative, the destination matrix will have the same type as the source.}
\cvarg{alpha}{The optional scale factor}
\cvarg{beta}{The optional delta, added to the scaled values.}
\end{description}
The method converts source pixel values to the target datatype. \texttt{saturate\_cast<>} is applied in the end to avoid possible overflows:
\cvarg{cn}{The new number of channels. If the parameter is 0, the number of channels remains the same.}
\cvarg{rows}{The new number of rows. If the parameter is 0, the number of rows remains the same.}
\end{description}
The method makes a new matrix header for \texttt{*this} elements. The new matrix may have different size and/or different number of channels. Any combination is possible, as long as:
\begin{enumerate}
\item No extra elements is included into the new matrix and no elements are excluded. Consequently,
the product \texttt{rows*cols*channels()} must stay the same after the transformation.
\item No data is copied, i.e. this is O(1) operation. Consequently, if you change the number of rows, or the operation changes elements' row indices in some other way, the matrix must be continuous. See \cvCppCross{Mat::isContinuous}.
\end{enumerate}
Here is some small example. Assuming, there is a set of 3D points that are stored as STL vector, and you want to represent the points as \texttt{3xN} matrix. Here is how it can be done:
\begin{lstlisting}
std::vector<cv::Point3f> vec;
...
Mat pointMat = Mat(vec). // convert vector to Mat, O(1) operation
reshape(1). // make Nx3 1-channel matrix out of Nx1 3-channel.
It does not perform the actual transposition, but returns a temporary "matrix transposition" object that can be further used as a part of more complex matrix expression or be assigned to a matrix:
\cvarg{method}{The matrix inversion method, one of}
\begin{description}
\cvarg{DECOMP\_LU}{LU decomposition. The matrix must be non-singular}
\cvarg{DECOMP\_CHOLESKY}{Cholesky $LL^T$ decomposition, for symmetrical positively defined matrices only. About twice faster than LU on big matrices.}
\cvarg{DECOMP\_SVD}{SVD decomposition. The matrix can be a singular or even non-square, then the pseudo-inverse is computed}
\end{description}
\end{description}
The method performs matrix inversion by means of matrix expressions, i.e. a temporary "matrix inversion" object is returned by the method, and can further be used as a part of more complex matrix expression or be assigned to a matrix.
\cvCppFunc{Mat::mul}
Performs element-wise multiplication or division of the two matrices
The method returns a temporary object encoding per-element array multiplication, with optional scale. Note that this is not a matrix multiplication, which corresponds to a simpler "*" operator.
Mat C = A.mul(5/B); // equivalent to divide(A, B, C, 5)
\end{lstlisting}
\cvCppFunc{Mat::cross}
Computes cross-product of two 3-element vectors
\cvdefCpp{
Mat Mat::cross(const Mat\& m) const;
}
\begin{description}
\cvarg{m}{Another cross-product operand}
\end{description}
The method computes cross-product of the two 3-element vectors. The vectors must be 3-elements floating-point vectors of the same shape and the same size. The result will be another 3-element vector of the same shape and the same type as operands.
\cvCppFunc{Mat::dot}
Computes dot-product of two vectors
\cvdefCpp{
double Mat::dot(const Mat\& m) const;
}
\begin{description}
\cvarg{m}{Another dot-product operand.}
\end{description}
The method computes dot-product of the two matrices. If the matrices are not single-column or single-row vectors, the top-to-bottom left-to-right scan ordering is used to treat them as 1D vectors. The vectors must have the same size and the same type. If the matrices have more than one channel, the dot products from all the channels are summed together.
The method returns Matlab-style zero array initializer. It can be used to quickly form a constant array and use it as a function parameter, as a part of matrix expression, or as a matrix initializer.
Note that in the above sample a new matrix will be allocated only if \texttt{A} is not 3x3 floating-point matrix, otherwise the existing matrix \texttt{A} will be filled with 0's.
The method returns Matlab-style ones' array initializer, similarly to \cvCppCross{Mat::zeros}. Note that using this method you can initialize an array with arbitrary value, using the following Matlab idiom:
The above operation will not form 100x100 matrix of ones and then multiply it by 3. Instead, it will just remember the scale factor (3 in this case) and use it when actually invoking the matrix initializer.
The method returns Matlab-style identity matrix initializer, similarly to \cvCppCross{Mat::zeros}. Similarly to \texttt{Mat::ones}, you can use a scale operation to create a scaled identity matrix efficiently:
This is one of the key \texttt{Mat} methods. Most new-style OpenCV functions and methods that produce arrays call this method for each output array. The method uses the following algorithm:
Such a scheme makes the memory management robust and efficient at the same time, and also saves quite a bit of typing for the user, i.e. usually there is no need to explicitly allocate output arrays. That is, instead of writing:
\begin{lstlisting}
Mat color;
...
Mat gray(color.rows, color.cols, color.depth());
cvtColor(color, gray, CV_BGR2GRAY);
\end{lstlisting}
you can simply write:
\begin{lstlisting}
Mat color;
...
Mat gray;
cvtColor(color, gray, CV_BGR2GRAY);
\end{lstlisting}
because \texttt{cvtColor}, as well as most of OpenCV functions, calls Mat::create() for the output array internally.
The method increments the reference counter, associated with the matrix data. If the matrix header points to an external data (see \cvCppCross{Mat::Mat}), the reference counter is NULL, and the method has no effect in this case. Normally, the method should not be called explicitly, to avoid memory leaks. It is called implicitly by the matrix assignment operator. The reference counter increment is the atomic operation on the platforms that support it, thus it is safe to operate on the same matrices asynchronously in different threads.
\cvCppFunc{Mat::release}
Decrements the reference counter and deallocates the matrix if needed
\cvdefCpp{
void Mat::release();
}
The method decrements the reference counter, associated with the matrix data. When the reference counter reaches 0, the matrix data is deallocated and the data and the reference counter pointers are set to NULL's. If the matrix header points to an external data (see \cvCppCross{Mat::Mat}), the reference counter is NULL, and the method has no effect in this case.
This method can be called manually to force the matrix data deallocation. But since this method is automatically called in the destructor, or by any other method that changes the data pointer, it is usually not needed. The reference counter decrement and check for 0 is the atomic operation on the platforms that support it, thus it is safe to operate on the same matrices asynchronously in different threads.
The method changes the number of matrix rows. If the matrix is reallocated, the first \texttt{min(Mat::rows, sz)} rows are preserved. The method emulates the corresponding method of STL vector class.
The methods add one or more elements to the bottom of the matrix. They emulate the corresponding method of STL vector class. When \texttt{elem} is \texttt{Mat}, its type and the number of columns must be the same as in the container matrix.
\cvarg{wholeSize}{The output parameter that will contain size of the whole matrix, which \texttt{*this} is a part of.}
\cvarg{ofs}{The output parameter that will contain offset of \texttt{*this} inside the whole matrix}
\end{description}
After you extracted a submatrix from a matrix using \cvCppCross{Mat::row}, \cvCppCross{Mat::col}, \cvCppCross{Mat::rowRange}, \cvCppCross{Mat::colRange} etc., the result submatrix will point just to the part of the original big matrix. However, each submatrix contains some information (represented by \texttt{datastart} and \texttt{dataend} fields), using which it is possible to reconstruct the original matrix size and the position of the extracted submatrix within the original matrix. The method \texttt{locateROI} does exactly that.
\cvCppFunc{Mat::adjustROI}
Adjust submatrix size and position within the parent matrix
\cvdefCpp{
Mat\& Mat::adjustROI( int dtop, int dbottom, int dleft, int dright );
}
\begin{description}
\cvarg{dtop}{The shift of the top submatrix boundary upwards}
\cvarg{dbottom}{The shift of the bottom submatrix boundary downwards}
\cvarg{dleft}{The shift of the left submatrix boundary to the left}
\cvarg{dright}{The shift of the right submatrix boundary to the right}
\end{description}
The method is complimentary to the \cvCppCross{Mat::locateROI}. Indeed, the typical use of these functions is to determine the submatrix position within the parent matrix and then shift the position somehow. Typically it can be needed for filtering operations, when pixels outside of the ROI should be taken into account. When all the method's parameters are positive, it means that the ROI needs to grow in all directions by the specified amount, i.e.
\begin{lstlisting}
A.adjustROI(2, 2, 2, 2);
\end{lstlisting}
increases the matrix size by 4 elements in each direction and shifts it by 2 elements to the left and 2 elements up, which brings in all the necessary pixels for the filtering with 5x5 kernel.
It's user responsibility to make sure that adjustROI does not cross the parent matrix boundary. If it does, the function will signal an error.
The function is used internally by the OpenCV filtering functions, like \cvCppCross{filter2D}, morphological operations etc.
See also \cvCppCross{copyMakeBorder}.
\cvCppFunc{Mat::operator()}
Extracts a rectangular submatrix
\cvdefCpp{
Mat Mat::operator()( Range rowRange, Range colRange ) const;\newline
\cvarg{rowRange}{The start and the end row of the extracted submatrix. The upper boundary is not included. To select all the rows, use \texttt{Range::all()}}
\cvarg{colRange}{The start and the end column of the extracted submatrix. The upper boundary is not included. To select all the columns, use \texttt{Range::all()}}
\cvarg{roi}{The extracted submatrix specified as a rectangle}
The operators make a new header for the specified sub-array of \texttt{*this}. They are the most generalized forms of \cvCppCross{Mat::row}, \cvCppCross{Mat::col}, \cvCppCross{Mat::rowRange} and \cvCppCross{Mat::colRange}. For example, \texttt{A(Range(0, 10), Range::all())} is equivalent to \texttt{A.rowRange(0, 10)}. Similarly to all of the above, the operators are O(1) operations, i.e. no matrix data is copied.
The operator makes CvMat header for the matrix without copying the underlying data. The reference counter is not taken into account by this operation, thus you should make sure than the original matrix is not deallocated while the \texttt{CvMat} header is used. The operator is useful for intermixing the new and the old OpenCV API's, e.g:
The operator makes IplImage header for the matrix without copying the underlying data. You should make sure than the original matrix is not deallocated while the \texttt{IplImage} header is used. Similarly to \texttt{Mat::operator CvMat}, the operator is useful for intermixing the new and the old OpenCV API's.
The method returns true if the matrix elements are stored continuously, i.e. without gaps in the end of each row, and false otherwise. Obviously, \texttt{1x1} or \texttt{1xN} matrices are always continuous. Matrices created with \cvCppCross{Mat::create} are always continuous, but if you extract a part of the matrix using \cvCppCross{Mat::col}, \cvCppCross{Mat::diag} etc. or constructed a matrix header for externally allocated data, such matrices may no longer have this property.
The continuity flag is stored as a bit in \texttt{Mat::flags} field, and is computed automatically when you construct a matrix header, thus the continuity check is very fast operation, though it could be, in theory, done as following:
\begin{lstlisting}
// alternative implementation of Mat::isContinuous()
The method is used in a quite a few of OpenCV functions, and you are welcome to use it as well. The point is that element-wise operations (such as arithmetic and logical operations, math functions, alpha blending, color space transformations etc.) do not depend on the image geometry, and thus, if all the input and all the output arrays are continuous, the functions can process them as very long single-row vectors. Here is the example of how alpha-blending function can be implemented.
This trick, while being very simple, can boost performance of a simple element-operation by 10-20 percents, especially if the image is rather small and the operation is quite simple.
Also, note that we use another OpenCV idiom in this function - we call \cvCppCross{Mat::create} for the destination array instead of checking that it already has the proper size and type. And while the newly allocated arrays are always continuous, we still check the destination array, because \cvCppCross{create} does not always allocate a new matrix.
\cvCppFunc{Mat::elemSize}
Returns matrix element size in bytes
\cvdefCpp{
size\_t Mat::elemSize() const;
}
The method returns the matrix element size in bytes. For example, if the matrix type is \texttt{CV\_16SC3}, the method will return \texttt{3*sizeof(short)} or 6.
\cvCppFunc{Mat::elemSize1}
Returns size of each matrix element channel in bytes
\cvdefCpp{
size\_t Mat::elemSize1() const;
}
The method returns the matrix element channel size in bytes, that is, it ignores the number of channels. For example, if the matrix type is \texttt{CV\_16SC3}, the method will return \texttt{sizeof(short)} or 2.
\cvCppFunc{Mat::type}
Returns matrix element type
\cvdefCpp{
int Mat::type() const;
}
The method returns the matrix element type, an id, compatible with the \texttt{CvMat} type system, like \texttt{CV\_16SC3} or 16-bit signed 3-channel array etc.
\cvCppFunc{Mat::depth}
Returns matrix element depth
\cvdefCpp{
int Mat::depth() const;
}
The method returns the matrix element depth id, i.e. the type of each individual channel. For example, for 16-bit signed 3-channel array the method will return \texttt{CV\_16S}. The complete list of matrix types:
The method returns true if \texttt{Mat::total()} is 0 or if \texttt{Mat::data} is NULL. Because of \texttt{pop\_back()} and \texttt{resize()} methods \texttt{M.total() == 0} does not imply that \texttt{M.data == NULL}.
The methods return \texttt{uchar*} or typed pointer to the specified matrix row. See the sample in \cvCppCross{Mat::isContinuous}() on how to use these methods.
The template methods return reference to the specified array element. For the sake of higher performance the index range checks are only performed in Debug configuration.
Note that the variants with a single index (i) can be used to access elements of single-row or single-column 2-dimensional arrays. That is, if, for example, \texttt{A} is \texttt{1 x N} floating-point matrix and \texttt{B} is \texttt{M x 1} integer matrix, you can simply write \texttt{A.at<float>(k+4)} and \texttt{B.at<int>(2*i+1)} instead of \texttt{A.at<float>(0,k+4)} and \texttt{B.at<int>(2*i+1,0)}, respectively.
Here is an example of initialization of a Hilbert matrix:
The methods return the matrix read-only or read-write iterators. The use of matrix iterators is very similar to the use of bi-directional STL iterators. Here is the alpha blending function rewritten using the matrix iterators:
The class \texttt{Mat\_<\_Tp>} is a "thin" template wrapper on top of \texttt{Mat} class. It does not have any extra data fields, nor it or \texttt{Mat} have any virtual methods and thus references or pointers to these two classes can be freely converted one to another. But do it with care, e.g.:
\begin{lstlisting}
// create 100x100 8-bit matrix
Mat M(100,100,CV_8U);
// this will compile fine. no any data conversion will be done.
Mat_<float>& M1 = (Mat_<float>&)M;
// the program will likely crash at the statement below
M1(99,99) = 1.f;
\end{lstlisting}
While \texttt{Mat} is sufficient in most cases, \texttt{Mat\_} can be more convenient if you use a lot of element access operations and if you know matrix type at compile time. Note that \texttt{Mat::at<\_Tp>(int y, int x)} and \texttt{Mat\_<\_Tp>::operator ()(int y, int x)} do absolutely the same and run at the same speed, but the latter is certainly shorter:
The class is used for implementation of unary, binary and, generally, n-ary element-wise operations on multi-dimensional arrays. Some of the arguments of n-ary function may be continuous arrays, some may be not. It is possible to use conventional \cross{MatIterator}'s for each array, but it can be a big overhead to increment all of the iterators after each small operations. That's where \texttt{NAryMatIterator} can be used. Using it, you can iterate though several matrices simultaneously as long as they have the same geometry (dimensionality and all the dimension sizes are the same). On each iteration \texttt{it.planes[0]}, \texttt{it.planes[1]}, ... will be the slices of the corresponding matrices.
The class \texttt{SparseMat} represents multi-dimensional sparse numerical arrays. Such a sparse array can store elements of any type that \cross{Mat} can store. "Sparse" means that only non-zero elements are stored (though, as a result of operations on a sparse matrix, some of its stored elements can actually become 0. It's up to the user to detect such elements and delete them using \texttt{SparseMat::erase}). The non-zero elements are stored in a hash table that grows when it's filled enough, so that the search time is O(1) in average (regardless of whether element is there or not). Elements can be accessed using the following methods:
\item query operations (\texttt{SparseMat::ptr} and the higher-level \texttt{SparseMat::ref}, \texttt{SparseMat::value} and \texttt{SparseMat::find}), e.g.:
\begin{lstlisting}
const int dims = 5;
int size[] = {10, 10, 10, 10, 10};
SparseMat sparse_mat(dims, size, CV_32F);
for(int i = 0; i < 1000; i++)
{
int idx[dims];
for(int k = 0; k < dims; k++)
idx[k] = rand()%sparse_mat.size(k);
sparse_mat.ref<float>(idx) += 1.f;
}
\end{lstlisting}
\item sparse matrix iterators. Like \cross{Mat} iterators and unlike \cross{MatND} iterators, the sparse matrix iterators are STL-style, that is, the iteration loop is familiar to C++ users:
\begin{lstlisting}
// prints elements of a sparse floating-point matrix
// and the sum of elements.
SparseMatConstIterator_<float>
it = sparse_mat.begin<float>(),
it_end = sparse_mat.end<float>();
double s = 0;
int dims = sparse_mat.dims();
for(; it != it_end; ++it)
{
// print element indices and the element value
const Node* n = it.node();
printf("(")
for(int i = 0; i < dims; i++)
printf("%3d%c", n->idx[i], i < dims-1 ? ',' : ')');
printf(": %f\n", *it);
s += *it;
}
printf("Element sum is %g\n", s);
\end{lstlisting}
If you run this loop, you will notice that elements are enumerated in no any logical order (lexicographical etc.), they come in the same order as they stored in the hash table, i.e. semi-randomly. You may collect pointers to the nodes and sort them to get the proper ordering. Note, however, that pointers to the nodes may become invalid when you add more elements to the matrix; this is because of possible buffer reallocation.
\item a combination of the above 2 methods when you need to process 2 or more sparse matrices simultaneously, e.g. this is how you can compute unnormalized cross-correlation of the 2 floating-point sparse matrices:
\begin{lstlisting}
double cross_corr(const SparseMat& a, const SparseMat& b)
{
const SparseMat *_a = &a, *_b = &b;
// if b contains less elements than a,
// it's faster to iterate through b
if(_a->nzcount() > _b->nzcount())
std::swap(_a, _b);
SparseMatConstIterator_<float> it = _a->begin<float>(),
it_end = _a->end<float>();
double ccorr = 0;
for(; it != it_end; ++it)
{
// take the next element from the first matrix
float avalue = *it;
const Node* anode = it.node();
// and try to find element with the same index in the second matrix.
// since the hash value depends only on the element index,
