A Unix, Windows, Raspberry Pi Object Speed Camera using python, opencv, video streaming, motion tracking. Includes a Standalone Web Server Interface, Image Search using opencv template match and a whiptail Admin Menu Interface Includes picam and webcam Plugins for motion track security camera configuration including rclone sync script. watch-app allows remotely controller camera configuration from a remote storage service name. Uses sqlite3 and gnuplot for reporting. Recently added openalpr license plate reader support.
Apache License 2.0
960
stars
169
forks
source link
option to perspective-warp the input image before motion-detection #153
Adds a MO_WARP_ON option that, if True, uses opencv's perspective warp to warp the image such that the four points specified in MO_WARP_INPUT_PTS become located at the points specified in MO_WARP_OUTPUT_PTS.
The points are specified as a list of two-element lists. The points are in clockwise format [bottom-left, top-left, top right, bottom right]. The points are calculated against the 320x240 image (not the source resolution of the camera).
On my 4gb Raspberry Pi 4, this costs about 1% of FPS (from 16.17fps to 15.98fps) -- i.e. the performance cost is negligible.
The reason for this PR is that my street curves within the motion tracking crop area -- so pixel distances within the crop area don't have a consistent relationship to real-world distances in feet/meters/miles. I decided to crop the area to make the distances consistent.
I don't anticipate that this PR is ready to be merged right away, so happy to address any questions.
Adds a
MO_WARP_ONoption that, ifTrue, uses opencv's perspective warp to warp the image such that the four points specified inMO_WARP_INPUT_PTSbecome located at the points specified inMO_WARP_OUTPUT_PTS.The points are specified as a list of two-element lists. The points are in clockwise format [bottom-left, top-left, top right, bottom right]. The points are calculated against the 320x240 image (not the source resolution of the camera).
On my 4gb Raspberry Pi 4, this costs about 1% of FPS (from 16.17fps to 15.98fps) -- i.e. the performance cost is negligible.
The reason for this PR is that my street curves within the motion tracking crop area -- so pixel distances within the crop area don't have a consistent relationship to real-world distances in feet/meters/miles. I decided to crop the area to make the distances consistent.
I don't anticipate that this PR is ready to be merged right away, so happy to address any questions.