[3rd attempt] fixed HOGDescriptor::detectMultiScale() to group weights as well as ROIs
Reverted back to the previous method where a public method groupRectangles was added to HOGDescriptor to take care of ROI and weight grouping
Added spacing in a nested template argument list.
The initial commit for generic optimization

Generic optimization package for openCV project, will be developed
between the June and September of 2013. This work is funded by Google
Summer of Code 2013 project. This project is about
implementing several algorithms, that will find global maxima/minima of a
given function on a given domain subject to a given constraints.

All comments/suggestions are warmly appreciated and to be sent to
alozz1991@gmail.com (please, mention the word "openCV" in topic of
message, for I'm using the spam-filters)
1. created module bioinspired. 2.transfered Retina module into the new module bioinspired. 3. added a fast tone mapping method to Retina interface and wrapped existing reinafilter dedicated method
updated demos and tutorial regarding the Retina class transfer to bioinspired module.
minor correction after buildbot warnings
last warnings solved
Starting implement simplex algorithm.
Blank module and first draft of solver API.

At this point we have a skeleton of a new module (optim) which can
barely compile properly (unlike previous commit). Besides, there is a
first draft of solver and lpsolver (linear optimization solver) in this
commit.
added documentation for OpenGL interoperability
Created skeleton for simplex method.

Added LPSolver class together with two nested classes: LPFunction and
LPConstraints. These represent function to be maximized and constraints
imposed respectively. They are implementations of interfaces Function
and Constraints respectively (latter ones are nested classes of Solver
interface, which is generic interface for all optimization algorithms to
be implemented within this project).

The next step is to implement the simplex algorithm! First, we shall
implement it for the case of constraints of the form Ax<=b and x>=0.
Then, we shall extend the sets of problems that can be handled by the
conversion to the one we've handled already. Finally, we shale
concentrate on numerical stability and efficiency.
Add super resolution's OpenCL implementation.
Accuracy and performance tests are also provided.
Fix build error.
The first draft of simplex algorithm, simple tests.

What we have now corresponds to "formal simplex algorithm", described in
Cormen's "Intro to Algorithms". It will work *only* if the initial
problem has (0,0,0,...,0) as feasible solution (consequently, it will
work unpredictably if problem was unfeasible or did not have zero-vector as
feasible solution). Moreover, it might cycle.

TODO (first priority)
1. Implement initialize_simplex() procedure, that shall check for
feasibility and generate initial feasible solution. (in particular, code
should pass all 4 tests implemented at the moment)
2. Implement Bland's rule to avoid cycling.
3. Make the code more clear.
4. Implement several non-trivial tests (??) and check algorithm against
them. Debug if necessary.

TODO (second priority)
1. Concentrate on stability and speed (make difficult tests)
JavaCameraView delivers same frame twice (Bug #3123) fixed.
allow QtKit capture in secondary threads

[NSRunLoop currentRunLoop] is not the same as in the main thread.
see
https://developer.apple.com/library/mac/#documentation/Cocoa/Reference/F
oundation/Classes/nsrunloop_Class/Reference/Reference.html
"If no input sources or timers are attached to the run loop, this
method exits immediately"

The old code caused grabFrame() to return immediately if the capture
was not done in the main thread.
This code works correctly, even in secondary threads, provided that all
capture functions are called in the *same* thread
PvAPI support on Windows with MinGW (PR #1038 applied to the branch 2.4)
add kmeans
Non-optimized simplex algorithm.

This version is supposed to work on all problems (please, let me know if
this is not so), but is not optimized yet in terms of numerical
stability and performance. Bland's rule is implemented as well, so
algorithm is supposed to allow no cycling. Additional check for multiple
solutions is added (in case of multiple solutions algorithm returns an
appropriate return code of 1 and returns arbitrary optimal solution).
Finally, now we have 5 tests.

Before Thursday we have 4 directions that can be tackled in parallel:
*) Prepare the pull request!
*) Make the code more clear and readable (refactoring)
*) Wrap the core solveLP() procedure in OOP-style interface
*) Test solveLP on non-trivial tests (possibly test against
http://www.coin-or.org/Clp/)