@@ -126,6 +128,8 @@ Define operator '()' to perform detection of KeyLines and computation of descrip
:param useProvidedKeyLines: flag (when set to true, detection phase will be skipped and only computation of descriptors will be executed, using lines provided in *keylines*)
:param returnFloatDescr: flag (when set to true, original non-binary descriptors are returned)
BinaryDescriptor::read
----------------------
...
...
@@ -171,14 +175,6 @@ Return descriptor size
.. ocv:function:: int BinaryDescriptor::descriptorSize() const
@@ -79,19 +81,10 @@ Apart from fields inspired to KeyPoint class, KeyLines stores information about
};
Lines extraction methodology
----------------------------
The lines extraction methodology described in the following is mainly based on [LBD]_.
The extraction starts with a Gaussian pyramid generated from an original image, downsampled N-1 times, blurred N times, to obtain N layers (one for each octave), with layer 0 corresponding to input image. Then, from each layer (octave) in the pyramid, lines are extracted using LSD algorithm.
Differently from EDLine lines extractor used in original article, LSD furnishes information only about lines extremes; thus, additional information regarding slope and equation of line are computed via analytic methods. The number of pixels is obtained using `LineIterator <http://docs.opencv.org/modules/core/doc/drawing_functions.html#lineiterator>`_. Later on, all extracted lines are arranged in buckets: two lines fall in the same bucket if they represent the same line in different octave (they have the same direction and belong to same region of original image). The set of buckets becomes the input for descriptors computation.
Computation of binary descriptors
---------------------------------
To obtatin a binary descriptor representing a certain line detected from a certain octave of an image, we first compute a non-binary descriptor as described in [LBD]_. Given a line, we consider a rectangular region centered at it and called *line support region (LSR)*. Such region is divided into a set of bands :math:`\{B_1, B_2, ..., B_m\}`, whose length equals the one of line.
To obtatin a binary descriptor representing a certain line detected from a certain octave of an image, we first compute a non-binary descriptor as described in [LBD]_. Such algorithm works on lines extracted using EDLine detector, as explained in [EDL]_. Given a line, we consider a rectangular region centered at it and called *line support region (LSR)*. Such region is divided into a set of bands :math:`\{B_1, B_2, ..., B_m\}`, whose length equals the one of line.
If we indicate with :math:`\bf{d}_L` the direction of line, the orthogonal and clockwise direction to line :math:`\bf{d}_{\perp}` can be determined; these two directions, are used to construct a reference frame centered in the middle point of line. The gradients of pixels :math:`\bf{g'}` inside LSR can be projected to the newly determined frame, obtaining their local equivalent :math:`\bf{g'} = (\bf{g}^T \cdot \bf{d}_{\perp}, \bf{g}^T \cdot \bf{d}_L)^T \triangleq (\bf{g'}_{d_{\perp}}, \bf{g'}_{d_L})^T`.
* use the `BinaryDescriptor <binary_descriptor.html>`_ interface to extract lines and store them in *KeyLine* objects
* use the *BinaryDescriptor* interface to extract lines and store them in *KeyLine* objects
* use the same interface to compute descriptors for every extracted line
* use the `BynaryDescriptorMatcher <matching.html#binarydescriptormatcher-class>`_ to determine matches among descriptors obtained from different images
* use the *BynaryDescriptorMatcher* to determine matches among descriptors obtained from different images
Lines extraction and descriptors computation
...
...
@@ -101,12 +101,32 @@ In the following snippet of code, it is shown how to detect lines from an image.
This is the result obtained for famous cameraman image:
.. image:: pics/cameraman_lines2.png
.. image:: pics/lines_cameraman_edl.png
:width: 512px
:align: center
:height: 512px
:alt: alternate text
Another way to extract lines is using *LSDDetector* class; such class uses the LSD extractor to compute lines. To obtain this result, it is sufficient to use the snippet code seen above, just modifying it by the rows
Here's the result returned by LSD detector again on cameraman picture:
.. image:: pics/cameraman_lines2.png
:width: 512px
:align: center
:height: 512px
:alt: alternate text
Once keylines have been detected, it is possible to compute their descriptors as shown in the following:
...
...
@@ -299,9 +319,9 @@ Here's an example om matching among descriptors extratced from original camerama
Querying internal database
--------------------------
The `BynaryDescriptorMatcher <matching.html#binarydescriptormatcher-class>`_ class, owns an internal database that can be populated with descriptors extracted from different images and queried using one of the modalities described in previous section.
The *BynaryDescriptorMatcher* class, owns an internal database that can be populated with descriptors extracted from different images and queried using one of the modalities described in previous section.
Population of internal dataset can be done using the *add* function; such function doesn't directly add new data to database, but it just stores it them locally. The real update happens when function *train* is invoked or when any querying function is executed, since each of them invokes *train* before querying.
When queried, internal database not only returns required descriptors, but, for every returned match, it is able to say which image matched descriptor was extracted from.
When queried, internal database not only returns required descriptors, but, for every returned match, it is able to tell which image matched descriptor was extracted from.
An example of internal dataset usage is described in the following code; after adding locally new descriptors, a radius search is invoked. This provokes local data to be transferred to dataset, which, in turn, is then queried.
Long-term optical tracking is one of most important issue for many computer vision applications in real world scenario.
The development in this area is very fragmented and this API is an unique interface useful for plug several algorithms and compare them.
This work is partially based on [AAM]_ and [AMVOT]_.
This algorithms start from a bounding box of the target and with their internal representation they avoid the drift during the tracking.
These long-term trackers are able to evaluate online the quality of the location of the target in the new frame, without ground truth.
There are three main components: the TrackerSampler, the TrackerFeatureSet and the TrackerModel. The first component is the object that computes the patches over the frame based on the last target location.
The TrackerFeatureSet is the class that manages the Features, is possible plug many kind of these (HAAR, HOG, LBP, Feature2D, etc).
The last component is the internal representation of the target, it is the appearence model. It stores all state candidates and compute the trajectory (the most likely target states). The class TrackerTargetState represents a possible state of the target.
The TrackerSampler and the TrackerFeatureSet are the visual representation of the target, instead the TrackerModel is the statistical model.
A recent benchmark between these algorithms can be found in [OOT]_.
.. note:: This Tracking API has been designed with PlantUML. If you modify this API please change UML files under modules/tracking/misc/
The following reference was used in the API
.. [AAM] S Salti, A Cavallaro, L Di Stefano, Adaptive Appearance Modeling for Video Tracking: Survey and Evaluation, IEEE Transactions on Image Processing, Vol. 21, Issue 10, October 2012, pp. 4334-4348
.. [AMVOT] X Li, W Hu, C Shen, Z Zhang, A Dick, A van den Hengel, A Survey of Appearance Models in Visual Object Tracking, ACM Transactions on Intelligent Systems and Technology (TIST), 2013
.. [OOT] Yi Wu and Jongwoo Lim and Ming-Hsuan Yang, Online Object Tracking: A Benchmark, The IEEE Conference on Computer Vision and Pattern Recognition (CVPR), 2013
