stbt.match: Merge neighbouring ROIs from previous pyramid level

[drothlis]

If the previous pyramid level (that is, running cv2.matchTemplate on a
smaller version of the image) identified Regions Of Interest (ROIs)
that are small and close together, then at the next pyramid level we
have to invoke cv2.matchTemplate (now on the full-sized image)
multiple times.

This is still a worthwhile optimisation compared to running
cv2.matchTemplate on the entire full-sized image; but if we merge
ROIs that are very close together, it's even faster.

This effect is particularly pronounced, now that we've tightened the
match threshold, if you're looking for an image of a word and the frame
has a full paragraph of text; the word might (tentatively) match at
every word in the paragraph, but not at the spaces between the words.

In the above scenario, I measured 47ms vs. 69ms, on my laptop.

N.B. The morphological operation "Closing" means to dilate and then
erode -- it has the effect of closing holes or gaps. Using a square
kernel (all ones) is 4 times faster than using an elliptical kernel
(250µs for the c2v.morphologyEx vs. 1.1ms).

TODO:

• Fix match failures at edge locations.
• Measure the performance impact across a wider range of examples.

[drothlis]

	master (sqdiff @ 0.98)	this branch	v29 (sqdiff-normed @ 0.8)
Looking for this reference image:
In this frame:
ROIs identified at previous pyramid level:
Becomes ROIs in the full sized image:
Number of cv2.matchTemplate calls:	97	12	19
%timeit stbt.match(template, frame) takes:	69ms	47ms	54ms

[drothlis]

Ironically the old sqdiff-normed @ 0.80 takes 54ms: better than the current master, but not as fast as this PR.

Because the old threshold is more generous, the ROIs were more likely to be joined already.

[drothlis]

test_match_visualisation was failing because match locations at the very edge of the image were being eroded away. This was because I used an even-sized kernel. Changing the kernel size from 10 to 11 fixed it.

I have also made the kernel 11x11 instead of 11x1 (horizontal). Because why not, it should handle more cases. Performance of the cv2.morphologyEx went from 200µs -> 250µs.

Note that this filter is square (all ones). If I use an elliptical filter, cv2.morphologyEx takes 4x longer (1.1ms).

[drothlis]

Rebased onto master to get test fixes from #560.

[drothlis]

On 1518 template/screenshot pairs from a real test-pack (69 templates x 22 screenshots)

Greatest improvement (absolute): 130ms (37%)
Greatest improvement (relative): 44% (17ms)
Worst deterioration (absolute): 53ms (14%)
Worst deterioration (relative): 24% (22ms)

Average difference (absolute): 1.758s improvement

Here's the worst deterioration:

	master (sqdiff @ 0.98)	this branch
ROIs identified at pyramid level 2:
Becomes ROIs in pyramid level 1:
Time of stbt.match:	91ms	112ms

[drothlis]

Reducing the kernel size of the closing operation at the smallest pyramid level to (5,5) seems to be an improvement but still isn't unambiguously better than master:

Greatest improvement (absolute): 133ms (37%)
Greatest improvement (relative): 42% (106ms)
Worst deterioration (absolute): 59ms (31%)
Worst deterioration (relative): same one

Average improvement (absolute): 2.876s
(Edit: That can't be the average improvement because it's 20x larger than the greatest improvement. Unfortunately I can't find the spreadsheet where I did these calculations 2 weeks ago).

All the differences (positive means an improvement):

[drothlis]

There are almost as many regressions in performance as there are improvements, so I'm giving up on this idea.

[drothlis]

Reopening -- I want to revisit this now that we've merged #569.

[drothlis]

Average improvement of 7ms per match across 1200 screenshot×template pairs.