Improvements to cvFindChessboardCorners (Patch #545)

I made few improvements to cvFindChessboardCorners.

I had problems with chessboard in perspective, where dilation dilated quads in one direction more than in another. Because of this they have not connected properly together as they become too far apart. So I fixed icvFindQuadNeighbors to work also with such chessboard images.

• increased thresh_scale to 1.5 so that also corners which are apart for sqrt(2) (square diagonal) are matched
• changed what is used as a base for threshold for corner candidates: now mean of all edge lengths (squared) of a current connected group of quads is used and not just of two quads (possible neighbors we are checking)
• because of how threshold now operates (by mean) some corners/quads could be left out at the beginning which would later one be included as mean would expand with new quads
  • because of this I made around all this a loop which is repeated until no new corner/quads are added
• there is a check for closest quad if there is some other corner closer than current one, in this case those two corners were not merged
  • this prevented to merge some proper corners because those other closest corner could be invalid for some other reasons and would later on not be used
  • because of this I changed this into a two pass process, where in the first pass such corners are not merged (to allow proper other closest corners to be matched), in the second pass this check is not done anymore, so that those invalid corners do not prevent valid ones to merge
• because I increased radius of the area searched for neighboring corner candidates corners on the edge of the pattern could sometimes erroneously merge, this prevented later stages of chessboard finding algorithm to succeed
  • because of this I added additional check for corner candidates which checks if merging those two candidates would make a space between pattern's quads a triangle, and forbid such merge
  • this check is made by observation that between any two possible corners which are candidates for being merged (and their quads being marked as neighbors) there should be the shortest (alternative, before merging) path connecting those two corners along other edges of length at least four (if it even exists)
  • to assure the order in which this check is made (so that it prevents merge for corners which has the longest (thus less likely to be correct neighbor) distance between and not other corners in this (possible) triangle which could be correct ones) I made thresh_scale a variable which incrementally increases from 0.1 to 1.5 in a loop

In short, I changed algorithm to iteratively tries to improve what it has and not bailing out too soon. Implementation of this ideas could be probably improved a lot as currently it is quite brute-force approach blindly repeating things (it is still polynomial, but its degree increased a lot). But as calibration is not often time-critical I believe that successful matches are more important than failing fast by not matching (while match would be possible).

I am attaching a patch and images showing things described above.