Deployment Configuration

Metropolis Analytics microservices components are deployed as docker containers using docker compose.

Docker compose config file provide variables to configure at deployment time certain important parameters.

Note

Value name prefix is subject to change in future release.

Configuration parameters

Object Type based filtering (Multi-class)

Goal: Specify the type of objects (e.g Person, car, truck..) which analytics microservice will process for analytics.

Principle: When a model like Yolo8 which can detect large number of object types is used for perception, it may be useful to process only certain types of object and discard others.

  1. Object types to be processed for analytics

Effect: Specify the type of objects which the analytics microservice will process

  • config/emdx-analytics/config.yaml

  • Name: filters.state_management.class_target

  • Type: Array of string

  • Description: Specify object types which should be proccesed for analytics. The model deployed for perception determines the type of object which are detected. A wildcard ‘*’ means process all object types. A specific list like [car, truck] means only those object types are processed.

  • Default: single item ‘*’. This means all object types are processed.

  1. Object types to be processed for analytics api

Effect: Specify the type of objects which the analytics api microservice will process

  • config/emdx-webapi/config.yaml

  • Name: objectTypes

  • Type: Array of string

  • Description: Specify object types which should be proccesed for analytics. The model deployed for perception determines the type of object which are detected. A wildcard ‘*’ means process all object types. A specific list like [car, truck] means only those object types are processed.

  • Default: single item ‘*’. This means all object types are processed.

Note: Both A) and B) value should always match. That means if [car,truck] is specified for A it should also be specified for B as well.

Tripwire Spatial and Temporal buffers

Goal: Suppress noise of multiple crossings when the person or its detected bounding box jitters around the Tripwire line segments.

Principle: Decide crossing not just on single frame position but observe motion behavior over a time window and decide with confidence and provide stable results

These buffers parameters also defines the tradeoff between latency and accuracy that the user can make based on their use case.

  1. Spatial buffer: Specified in pixels

Effect: Not just crossed the tripwire line but also moved specified pixels away from it to be considered as a valid crossing.

  • config/emdx-analytics/config.yaml

  • Name: filters.tripwire.pixel_buffer

  • Type: Integer This defines the tradeoff between latency and accuracy that the user can make based on their use case.

  • Description: Number of pixels on either side of tripwire line which acts as buffer for suppressing jitters/loitering

  • Default: 15 pixels

  1. Temporal buffer: Specified in number of frames

Effect: Not just crossed the tripwire line but also found on the other side after crossing for specified number of video frames, to be considered as valid crossing.

  • config/emdx-analytics/config.yaml

  • Name: filters.tripwire.frame_buffer

  • Type: Integer

  • Description: Number of frames for which the persons is detected on other side of the tripwire for it considered crossing

  • Default: 5 frames

Important:

Both Spatial buffer and Temporal buffer criteria needs to be satisfied for a crossing to be considered as valid.

Accuracy vs latency

These buffers also defines the tradeoff between latency and accuracy that the user can make based on their use case. Higher the value for spatial and temporal buffer will in general result in higher accuracy at the cost of higher latency for counts to be reported after the actual crossing has happened.

ROI Spatial and Temporal buffers

Goal: Suppress noise of multiple crossings when the person or its detected bounding box jitters around the ROI line segments.

Principle: Decide occupancy not just on single frame position but observe motion behavior over a time window and decide with confidence and provide stable results

  1. Spatial buffer: Specified in pixels

Effect: Not just crossed the ROI line but also moved specified pixels away from it be considered present or absent in the ROI.

  • config/emdx-analytics/config.yaml

  • Name: filters.roi.pixel_buffer

  • Type: Integer

  • Description: Number of pixels on either side of ROI line which acts as buffer for suppressing jitters/loitering

  • Default: 15 pixels

  1. Temporal buffer: Specified in number of frames

Effect: Not just crossed the ROI line but also found on the other side after crossing for specified number of video frames, for it to be considered as valid crossing

  • config/emdx-analytics/config.yaml

  • Name: filters.roi.frame_buffer

  • Type: Integer

  • Description: Number of frames for which the persons is present on other side of the ROI for it to be considered as a valid crossing.

  • Default: 5 frames

Important: Both Spatial buffer and Temporal buffer criteria needs to be satisfied for a crossing to be considered as valid.

  1. Additional Temporal buffer: Specified in number of frames

Effect: If the B) Spatial buffer criteria is not satisfied but the person is found on the other side after crossing for specified number of video frames, then also it is to be considered as a valid crossing.

  • config/emdx-analytics/config.yaml

  • Name: filters.roi.frame_buffer_2

  • Type: Integer

  • Description: Number of frames for which the persons is detected on other side of the ROI for it to be considered as a valid crossing.

  • Default: 50 frames

Accuracy vs latency:

These buffers also defines the tradeoff between latency and accuracy that the user can make based on their use case. Higher the value for spatial and temporal buffer will in general result in higher accuracy at the cost of higher latency for counts to be reported after the actual crossing has happened.

FOV, Tripwire,ROI counts retention duration

FOV occupancy counts are stored in Redis timeseries keys. The counts are computed for each metadata frame and aggregated to 1 sec time window and written to Redis timeseries. High level time aggregations for window duration of 15sec, 1min, 15min are computed using this base 1 sec aggregation value.

The retention duration for each time window aggregation can be specified separately for FOV, Tripwire and ROI.

Following two configuration files contain those settings. The same settings needs to be applied to both the files.

  • config/emdx-analytics/config.yaml

  • config/emdx-webapi/cv_config.yaml

Top level variable for FOV:

  • Name: redis.timeseries.fov.tableGranularities.retention_msecs

  • Type: array of Time window aggregation object

  • Description: Contains an object for each time window aggregations (1sec, 15sec, 1min, 15min)

Top level variable for Tripwire:

  • Name: redis.timeseries.tripwire.tableGranularities.retention_msecs

  • Type: array of Time window aggregation object

  • Description: Contains an object for each time window aggregations (1sec, 15sec, 1min, 15min)

Top level variable for ROI:

  • Name: redis.timeseries.roi.tableGranularities.retention_msecs

  • Type: array of Time window aggregation object

  • Description: Contains an object for each time window aggregations (1sec, 15sec, 1min, 15min)

Time window aggregation object:

  • Name: retention_msecs

  • Type: integer

  • Description: Duration in milliseconds for which to retain counts for the specific time window aggregation in the Redis timeseries

Each retention object identifies its time window using unit and value variables.

  • 1 sec.unit=sec and value=1

  • 15 sec.unit=sec and value=15

  • 1 min.unit=min and value=1

  • 15 min.unit=min and value=15

Each time window aggregation has a default retention value which is as follows

  • 1 sec. 2678400000 msec. / 31 days

  • 15 sec. 8035200000 msec. / 93 days

  • 1 min. 16070400000 msec. / 186 days

  • 15 min. 32140800000 msec. / 372 days

Note: The values in both the config files should be modified and always match.

Alerts retention duration

The retention alerts data in the database can be configured using the following config variable.

Config file: config/emdx-webapi/cv_config.yaml

Variable:

  • Name: datastorage.alerts.retention_msecs

  • Type: integer

  • Description: Duration in milliseconds for which to retain the alerts in the SQLite DB

  • Default: 15552000000 milliseconds/ 180 days

Metadata retention duration

The retention frame level metadata in the filesystem can be configured using the following config variable.

Variable:

  • Name: metadatastorage.metadata.retention_msecs

  • Type: integer

  • Description: Duration in milliseconds for which to retain the vision metadata in the file system

  • Default: 604800000 milliseconds/ 7 days

Trajectory retention duration

The retention object level trajectory in the filesystem can be configured using the following config variable.

Variable:

  • Name: metadatastorage.trajectory.retention_msecs

  • Type: integer

  • Description: Duration in milliseconds for which to retain the trajectory in the file system

  • Default: 604800000 milliseconds/ 7 days