From version 1.16 all FLOW devices have the feature for automatic detection of poor visibility. This feature is parameterizable and is set for each analytic individually. It is designed for recognising both sudden and slow changes in the image that have an effect on the quality of the detection of traffic objects and their tracking. The visibility detector classified the situation into the following 3 states:

The state is represented in the form of the widget in the given analytic and is available via REST and Webhook interface and is automatically part of UDP data sentences and SDLC communication as a sensor error.

To achieve better robustness and adaptivity the visibility detector combines two indicators of poor visibility, the indicator based on the expected trajectory length in the defined polygon and an indicator based on the expected contrast. The evaluation happens in a cascade where in order for the poor visibility to be identified both indicators must indicate poor visibility. Both indicators have been defined to enable the visibility detector.

The trajectory indicator is based on the assumption that in low visibility, trajectories should be shortened since long-range detection is not possible. It, therefore, compares the average length of the trajectories in the defined time frame and zone with the reference length. To configure it, it is necessary to define a zone/polygon and set a minimum average length threshold and an evaluation time frame, along with a category filter to remove objects that may distort the measurement.

The trajectory indicator zone should be placed at a position where the trajectory lengths are the same for all objects of interest (regardless of direction). In other words, the dispersion of lengths is very low under normal visibility for the selected object categories. It should also be placed in a high-traffic position because it is better to prioritize this indicator over the contrast indicator. The minimum average length is defined in pixels and you can use the ruler tool to easily get the value (place the ruler in the position of the average trajectory in the zone). It is good to subtract approx. 5% of the length for a reserve.

The contrast indicator activates in cases when the trajectory indicator is in the “poor” state. The contrast indicator is based on the assumption that in poor visibility, the contrast in the scene is low. The contrast indicator is defined with a zone where the contrast is measured as well as the maximum negative difference against the reference value and evaluation period. To ensure adaptivity to natural changes in the image the reference value is regularly updated when the trajectory indicator state is “good” visibility.

The contrast polygon should be placed in a position with high and constant contrast no matter the time of day. To achieve a high contrast it is necessary that the bright area of the footage corresponds to the dark area. The position of the contrast indicator should be at a distance where visibility is still necessary with respect to the possibilities of the actual camera view. In scenes with unnatural lighting, we can use the horizontal road marking. The indicator automatically does not evaluate contrast in situations when there is a traffic object present in its defined area that causes the contrast to change artificially. When configuring the actual contrast in the zone the current contrast is indicated by the “current contrast” but be aware that it does not filter out traffic objects.

The image above shows examples of OK and NOK contrast zone positions. The first example from the left is not suitable because of the uniform texture (the contrast is about 2.0 which is very low). The second example has good contrast, but only temporarily because this is due to the shadow from the barrier which can change over time as the position of the sun changes. The last example represents a good location because the contrast is high during the day (> 40) and will be significant even at night if the road is artificially lit.

Note that when the contrast value drops below 10 then the indicator is in a “poor” visibility state no matter the setting. This is to protect against adaptation to an evidently bad image input. The same happens in case of the camera stream outage (e.g. permanent black image).

After configuring and activating the indicator the analytics will be re-initialized, this means that all data will be deleted. The visibility indicator is initialized in the “unknown” state. It stays in this state until the trajectory indicator starts indicating “good” visibility. Once this is the case, the reference value of the contrast indicator initializes.

Warning: The initialization of the visibility detector happens every time the source is re-initialized (for example because of user source redefinition), or when the device restarts.

The detector state is available in the form of a system String widget. Firstly it automatically propagates into the UDP and SDLC outputs. Secondly, the information about the detector state is available in the diagnostics section of the analytics.

The visibility state widget is hidden by default. If you want to see it on the dashboard you need to move it from the hidden widgets section. You can use the visibility state widget in expression widgets or its contents can be propagated using the Webhooks interface. It is also possible to get the detector state with a REST request on this address: /cubes/{cubeid}/analytics/{analytic_id}/info

In the case of UDP sinks the visibility error is propagated via Failure and FailureState (ObjectList and ZoneState sink). When the analytics is running and a visibility error is recognized the Failure is set to true and FailureState to EnvironmentalInterference.

In SDLC communication the information about poor visibility is communicated into each channel if the channel is in Basic Control mode, and is communicated as Open Loop Error.

Thanks to this feature it is possible to detect situations when the sensor is not working reliably or not at all. This information is propagated in the system via the system widget and is automatically present in the UDP, respectively SDLC interface. When activating this feature we also recommend activating auto-recovery mode to ensure maximum reliability of the sensor, for example for adaptive traffic control use.