Documenting imgproc module

- disabled doxygen tree
- enabled doxygen enum listing
- added imgproc reference to main page
- enabled BiB support
- chenged doxygen root page format
This commit is contained in:
Maksim Shabunin
2014-11-13 14:34:04 +03:00
parent 32348604e3
commit 555fdf893a
14 changed files with 4429 additions and 922 deletions

View File

@@ -194,22 +194,27 @@ enum KmeansFlags {
KMEANS_USE_INITIAL_LABELS = 1
};
enum { FILLED = -1,
LINE_4 = 4,
LINE_8 = 8,
LINE_AA = 16
};
//! type of line
enum LineTypes {
FILLED = -1,
LINE_4 = 4, //!< 4-connected line
LINE_8 = 8, //!< 8-connected line
LINE_AA = 16 //!< antialiased line
};
enum { FONT_HERSHEY_SIMPLEX = 0,
FONT_HERSHEY_PLAIN = 1,
FONT_HERSHEY_DUPLEX = 2,
FONT_HERSHEY_COMPLEX = 3,
FONT_HERSHEY_TRIPLEX = 4,
FONT_HERSHEY_COMPLEX_SMALL = 5,
FONT_HERSHEY_SCRIPT_SIMPLEX = 6,
FONT_HERSHEY_SCRIPT_COMPLEX = 7,
FONT_ITALIC = 16
};
//! Only a subset of Hershey fonts
//! <http://sources.isc.org/utils/misc/hershey-font.txt> are supported
enum HersheyFonts {
FONT_HERSHEY_SIMPLEX = 0, //!< normal size sans-serif font
FONT_HERSHEY_PLAIN = 1, //!< small size sans-serif font
FONT_HERSHEY_DUPLEX = 2, //!< normal size sans-serif font (more complex than FONT_HERSHEY_SIMPLEX)
FONT_HERSHEY_COMPLEX = 3, //!< normal size serif font
FONT_HERSHEY_TRIPLEX = 4, //!< normal size serif font (more complex than FONT_HERSHEY_COMPLEX)
FONT_HERSHEY_COMPLEX_SMALL = 5, //!< smaller version of FONT_HERSHEY_COMPLEX
FONT_HERSHEY_SCRIPT_SIMPLEX = 6, //!< hand-writing style font
FONT_HERSHEY_SCRIPT_COMPLEX = 7, //!< more complex variant of FONT_HERSHEY_SCRIPT_SIMPLEX
FONT_ITALIC = 16 //!< flag for italic font
};
enum ReduceTypes { REDUCE_SUM = 0, //!< the output is the sum of all rows/columns of the matrix.
REDUCE_AVG = 1, //!< the output is the mean vector of all rows/columns of the matrix.
@@ -2696,78 +2701,6 @@ CV_EXPORTS_W double kmeans( InputArray data, int K, InputOutputArray bestLabels,
//! @} core_cluster
//! @addtogroup imgproc_drawing
//! @{
/*! @brief Line iterator
The class is used to iterate over all the pixels on the raster line
segment connecting two specified points.
The class LineIterator is used to get each pixel of a raster line. It
can be treated as versatile implementation of the Bresenham algorithm
where you can stop at each pixel and do some extra processing, for
example, grab pixel values along the line or draw a line with an effect
(for example, with XOR operation).
The number of pixels along the line is stored in LineIterator::count.
The method LineIterator::pos returns the current position in the image:
@code{.cpp}
// grabs pixels along the line (pt1, pt2)
// from 8-bit 3-channel image to the buffer
LineIterator it(img, pt1, pt2, 8);
LineIterator it2 = it;
vector<Vec3b> buf(it.count);
for(int i = 0; i < it.count; i++, ++it)
buf[i] = *(const Vec3b)*it;
// alternative way of iterating through the line
for(int i = 0; i < it2.count; i++, ++it2)
{
Vec3b val = img.at<Vec3b>(it2.pos());
CV_Assert(buf[i] == val);
}
@endcode
*/
class CV_EXPORTS LineIterator
{
public:
/** @brief intializes the iterator
creates iterators for the line connecting pt1 and pt2
the line will be clipped on the image boundaries
the line is 8-connected or 4-connected
If leftToRight=true, then the iteration is always done
from the left-most point to the right most,
not to depend on the ordering of pt1 and pt2 parameters
*/
LineIterator( const Mat& img, Point pt1, Point pt2,
int connectivity = 8, bool leftToRight = false );
/** @brief returns pointer to the current pixel
*/
uchar* operator *();
/** @brief prefix increment operator (++it). shifts iterator to the next pixel
*/
LineIterator& operator ++();
/** @brief postfix increment operator (it++). shifts iterator to the next pixel
*/
LineIterator operator ++(int);
/** @brief returns coordinates of the current pixel
*/
Point pos() const;
uchar* ptr;
const uchar* ptr0;
int step, elemSize;
int err, count;
int minusDelta, plusDelta;
int minusStep, plusStep;
};
//! @} imgproc_drawing
//! @addtogroup core_basic
//! @{
@@ -2806,7 +2739,6 @@ public:
};
//////////////////////////////////////// Algorithm ////////////////////////////////////
class CV_EXPORTS Algorithm;

View File

@@ -353,43 +353,6 @@ inline unsigned RNG::next()
return (unsigned)state;
}
///////////////////////////////////////// LineIterator ////////////////////////////////////////
inline
uchar* LineIterator::operator *()
{
return ptr;
}
inline
LineIterator& LineIterator::operator ++()
{
int mask = err < 0 ? -1 : 0;
err += minusDelta + (plusDelta & mask);
ptr += minusStep + (plusStep & mask);
return *this;
}
inline
LineIterator LineIterator::operator ++(int)
{
LineIterator it = *this;
++(*this);
return it;
}
inline
Point LineIterator::pos() const
{
Point p;
p.y = (int)((ptr - ptr0)/step);
p.x = (int)(((ptr - ptr0) - p.y*step)/elemSize);
return p;
}
//! returns the next unifomly-distributed random number of the specified type
template<typename _Tp> static inline _Tp randu()
{

View File

@@ -804,6 +804,36 @@ public:
//! @{
/** @brief struct returned by cv::moments
The spatial moments \f$\texttt{Moments::m}_{ji}\f$ are computed as:
\f[\texttt{m} _{ji}= \sum _{x,y} \left ( \texttt{array} (x,y) \cdot x^j \cdot y^i \right )\f]
The central moments \f$\texttt{Moments::mu}_{ji}\f$ are computed as:
\f[\texttt{mu} _{ji}= \sum _{x,y} \left ( \texttt{array} (x,y) \cdot (x - \bar{x} )^j \cdot (y - \bar{y} )^i \right )\f]
where \f$(\bar{x}, \bar{y})\f$ is the mass center:
\f[\bar{x} = \frac{\texttt{m}_{10}}{\texttt{m}_{00}} , \; \bar{y} = \frac{\texttt{m}_{01}}{\texttt{m}_{00}}\f]
The normalized central moments \f$\texttt{Moments::nu}_{ij}\f$ are computed as:
\f[\texttt{nu} _{ji}= \frac{\texttt{mu}_{ji}}{\texttt{m}_{00}^{(i+j)/2+1}} .\f]
@note
\f$\texttt{mu}_{00}=\texttt{m}_{00}\f$, \f$\texttt{nu}_{00}=1\f$
\f$\texttt{nu}_{10}=\texttt{mu}_{10}=\texttt{mu}_{01}=\texttt{mu}_{10}=0\f$ , hence the values are not
stored.
The moments of a contour are defined in the same way but computed using the Green's formula (see
<http://en.wikipedia.org/wiki/Green_theorem>). So, due to a limited raster resolution, the moments
computed for a contour are slightly different from the moments computed for the same rasterized
contour.
@note
Since the contour moments are computed using Green formula, you may get seemingly odd results for
contours with self-intersections, e.g. a zero area (m00) for butterfly-shaped contours.
*/
class CV_EXPORTS_W_MAP Moments
{