Age | Commit message (Collapse) | Author |
|
|
|
|
|
Use square root of area. Otherwise very small bright points are unfairly
used.
|
|
|
|
The binary frame needs to be used, not grayscale.
v2:
Use brightness for sorting points.
|
|
|
|
|
|
|
|
The new extractor we've been using doesn't take into account brightness
at all. All contours give is the ability to sort points by circularity.
v2:
Change the auto threshold point size range to 2->7 pixels radius.
Issue: #389
v3: sort by radius instead
|
|
Also, make the slider signify the max point radius (hence squaring).
|
|
We want double precision for POSIT. It's best for the type to be set in
ope place without the need to go over everything while switching it back
and forth during tests.
Machine epsilon for float is very small as per
<https://en.wikipedia.org/wiki/Machine_epsilon>. Also see the absurdly
high epsilon of 1e-4 of POSIT that we've had. With floats, making the
epsilon lower resulted in change deltas flushing to zero. This typically
led to the translation Z value being very unstable in PT.
After the epsilon and data type size changes the Z value is stable.
|
|
|
|
Issue: #318
cf. http://forum.il2sturmovik.ru/topic/2291-open-track/page-26
|
|
We no longer have this recurring problem since I enabled
ignoring executable bit changes on the Windows workstation.
|
|
This reverts commit 546cfb5ad52dcfe1421d1af5e7baeada588ac735.
@MathijsG points out that some users have red LEDs, not uniform white.
Issue: #355
|
|
The confusion stems from the max slider value. It's 255, not 100 as is
the default. Max pixel count change to 20 was confused as we'll counting
area and not radius here. Taking into account that the value was divided
by 100 previously, it's bit less than the previous one but not as
confused as then.
Reported-by: @MathijsG
Issue: #355
|
|
Remove redundant operation on the frame.
|
|
|
|
It's enabled only for automatic thresholding. With it on, it's possible
to keep tracking in normal light conditions without changing gain or
exposure beforehand.
It won't function on badly overexposed images, or with other bright
white colors in the frame. It should function on somewhat overexposed
images.
CPU usage is somewhat high, even taking advantage of all OpenCV SIMD
goodness as per the code. We can revert the change if user reception is
bad.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Saves few % of cpu load
|
|
256 is divisible by 8, also less cpu usage
|
|
Previously it was too slow to 640x480@75.
|
|
Closes #224
|