| Age | Commit message (Collapse) | Author |
|---|
|
Profiling over a longer time period showed a bottleneck
while iterating pixels with `cv::floodFill()'. Contours
are actually faster, and we have MeanShift to establish
the proper center basing on pixel intensities.
|
|
Also, changing "f" typedef to "float" won't break the build anymore.
|
|
|
|
The functions are almost identical so why not.
I removed several bits:
- weighting by squared pixel value is bad. weight by pixel
value instead.
- making the ROI twice as big doesn't make sense and makes for
misdetected blobs. remove it.
- switch radius coefficient to something doing less iterations.
- sprinkle some __restrict pointer qualifier.
- cv::floodfill invocation had some hardcoded flag value.
- point radius circle and the bullseye line length weren't
adjusted by scaling ratio. while the circle fitted the radius
tightly, it was now clutter, so I removed it, leaving only the
properly-scaled bullseye.
- brightness had to go sadly since it's not accumulated anymore.
|
|
|
|
This makes the point size text and point crosses not alias due to the
resize.
Due to nice pixel coordinate system, the cross-drawing lambda only needs
minimal changes.
|
|
- Pass `struct CamInfo' rather than several elements separately
- Reformat
- Return `struct CamInfo' together with the frame since then it's always valid
- Move the focal length formula into `struct CamInfo'
- Remove incorrect focal length formula rather than #if 0
- Pass some stuff by reference and not by pointer
|
|
|
|
- separate .{cpp,hpp} for few classes
- don't include namespaces globally; harmless but looks bad
anyway
- class with all public members to struct
|
|
It's multiplied by 3 just a few lines below. So ~2 is actually a
good lower bound.
|
|
With -D_USE_MATH_DEFINES MSVC defines the standard M_PI and
friends.
Since this preprocessor definition is now always passed as part
of the build system for MSVC. We can use M_PI as if on a
mission.
|
|
|
|
Adjust usages.
|
|
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
|
|
We can't depend on M_PI existing after including cmath.
|
|
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.
|
|
|
|
|
|
This reverts commit 546cfb5ad52dcfe1421d1af5e7baeada588ac735.
@MathijsG points out that some users have red LEDs, not uniform white.
Issue: #355
|
|
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.
|
|
|
|
|
|
|
|
There's a race here since further accesses to the points array aren't
protected by a mutex in the extractor class.
There's no race in "get_points()" in the extractor since it's only used
in same thread where updates take place.
|
|
Slowdown was caused by something else. I can no longer reproduce it.
|
|
|
|
|
|
|
|
Closes #224
|
