* Refactor EdgeTPU and CPU model handling to detector submodules.
* Fix selecting the correct detection device type from the config
* Remove detector type check when creating ObjectDetectProcess
* Fixes after rebasing to 0.11
* Add init file to detector folder
* Rename to detect_api
Co-authored-by: Nicolas Mowen <nickmowen213@gmail.com>
* Add unit test for LocalObjectDetector class
* Add configuration for model inputs
Support transforming detection regions to RGB or BGR.
Support specifying the input tensor shape. The tensor shape has a standard format ["BHWC"] when handed to the detector, but can be transformed in the detector to match the model shape using the model input_tensor config.
* Add documentation for new model config parameters
* Add input tensor transpose to LocalObjectDetector
* Change the model input tensor config to use an enumeration
* Updates for model config documentation
Co-authored-by: Nicolas Mowen <nickmowen213@gmail.com>
* -1 so ensure indexes are correct
* Catch case of zero division
* Due to the -1, it may be negative
* Ignore source of error
The error is occurring due to a detections bounding box starting beyond the frame, this should be immediately ignored
* Formatting
* Check horizontal placement as well
* Remove original frame clamping
* Starting working on adding motion toggle
* Add all info to mqtt command
* Send motion to correct funs
* Update mqtt docs
* Fixes for contingencies
* format
* mypy
* Tweak behavior
* Fix motion breaking frames
* Fix bad logic in detect set
* Always set value for motion boxes
* Toggle improve_contrast for cameras via MQTT
* Process parameter to mqtt toggle improve_contrast
* Update mqtt docs for improve_contrast topic
* Spacing
* Add class variable and update in process_frames
* Pass to constructor
* pass by reference mistake
* remove parameter
* remove parameter
* Add object ratio config parameters
Issue: #2948
* Add config test for object filter ratios
Issue: #2948
* Address review comments
- Accept `ratio` default
- Rename `bounds` to `box` for consistency
- Add migration for new field
Issue: #2948
* Fix logical errors
- field migrations require default values
- `clipped` referenced the wrong index for region, since it shifted
- missed an inclusion of `ratio` for detections in `process_frames`
- revert naming `o[2]` as `box` since it is out of scope!
This has now been test-run against a video, so I believe the kinks are
worked out.
Issue: #2948
* Update contributing notes for `make`
Issue: #2948
* Fix migration
- Ensure that defaults match between Event and migration script
- Deconflict migration script number (from rebase)
Issue: #2948
* Filter objects out of ratio bounds
Issue: #2948
* Update migration file to 009
Issue: #2948
Use config data classes to eliminate some of the boilerplate associated
with setting up the configuration. In particular, using dataclasses
removes a lot of the boilerplate around assigning properties to the
object and allows these to be easily immutable by freezing them. In the
case of simple, non-nested dataclasses, this also provides more
convenient `asdict` helpers.
To set this up, where previously the objects would be parsed from the
config via the `__init__` method, create a `build` classmethod that does
this and calls the dataclass initializer.
Some of the objects are mutated at runtime, in particular some of the
zones are mutated to set the color (this might be able to be refactored
out) and some of the camera functionality can be enabled/disabled. Some
of the configs with `enabled` properties don't seem to have mqtt hooks
to be able to toggle this, in particular, the clips, snapshots, and
detect can be toggled but rtmp and record configs do not, but all of
these configs are still not frozen in case there is some other
functionality I am missing.
There are a couple other minor fixes here, one that was introduced
by me recently where `max_seconds` was not defined, the other to
properly `get()` the message payload when handling publishing mqtt
messages sent via websocket.
Generally eliminate the `while True` loops while waiting for a stop
event and prefer to condition the loops on if the stop event is set,
blocking on that where it makes sense. This generally comes in 3
flavors. First and simplest, when there is a sleep and the stop event
is the only thing the loop blocks on, instead do a check using
`stop_event.wait(timeout)` to instead block on the stop event for the
designated amount of time. Second, when there is a different event that
is blocking in the loop, condition the loop on `stop_event.is_set()`
rather than breaking when it is set. Finally, when there is a separate
internal condition that requires a counter, have the loop iterate over
the counter and use `if stop_event.wait(timeout)` internal to the loop.
