Field scanning is currently done with scale NEAREST, which can misbehave on dirty input. A user may see missing blocks at various time during game play.
Approach
Remove the PIL-based scaling NEAREST
From the source image, grab a 3x3 pixel square in the middle of each block
Average all colors for these 9 pixels (with correct average of squares)
Supply computed color to the same closest-to-[black/white/color1/color2] algorithm as before
Bonus:
Add plenty of problematic easiercap frames that can be used to test new algorithms later
For discussion:
Maybe we don't need so many bad frames as sample inputs in the repo? 😅
Results
Performance
The new method is faster. Result below for 10,000 iterations:
the colors we extract from the board from the old algo (scale NEAREST, row 1) and new algo (custom 3x3, row 2)
The regenarated field from the reference colors after scanning
Side Note: The regenerated field (last column) shows that the hardcoded reference colors are quite far from the colors reported by the capture device in these example. As discussed previously, this highlights that the system should allow a user to supply a custom color palettes to match their setup.
Context
Field scanning is currently done with scale NEAREST, which can misbehave on dirty input. A user may see missing blocks at various time during game play.
Approach
Bonus:
For discussion:
Results
Performance
The new method is faster. Result below for 10,000 iterations:
Timing with old method:
Timing with new method
Capture Improvements
The images below show:
Side Note: The regenerated field (last column) shows that the hardcoded reference colors are quite far from the colors reported by the capture device in these example. As discussed previously, this highlights that the system should allow a user to supply a custom color palettes to match their setup.
The sample scripts can be run as: