CROSS-REFERENCE TO RELATED APPLICATION(S)

[0001] This application claims priority to U.S. Provisional Patent Application No. 63/198,97 filed on November 20, 2020, the contents of which are incorporated herein by reference.

TECHNICAL FIELD

[0002] The following relates generally to video configurations, in particular to automatically and/or semi-automatically configuring video for analyzing traffic video.

BACKGROUND

[0003] Video analytics has become a popular tool for Intelligent Transportation Systems (ITSs). In such systems, video can be used by roadside systems to detect vehicles, track objects through a scene, generate analytics, and respond in real-time. Computer vision algorithms are commonly used to detect and track vehicles through the scene. To generate accurate analytics and to properly respond to events, the system is required to miss very few vehicles and to rarely overcount. Therefore, ensuring that the vehicle is in the correct lane or mapped to the correct movement is considered important.

[0004] Video can present a problem in that the physical camera needs to be properly registered to a reference point in the real-world and everything that is configured in the video needs to match the behavior of the vehicles. For instance, if a vehicle is in a right lane, but the camera shifts or if the user configures the right lane and left lanes in a way that is ambiguous to the data, the system is likely unable to confidently respond to the vehicle. That is, the system would not know for sure if the vehicle is turning right or left. While these types of configurations are possible to do “by hand”, they are time-consuming and/or can be inaccurate. In many cases, the user performing the configuration may not even be able to understand how the computer vision algorithm is tracking the vehicle, let alone be able to design a configuration that best works with that algorithm.

[0005] Challenges with configurations can also include dealing with multiple views from a single camera, which challenges are common with wide or fisheye lenses, zooming concerns, and multiple cameras covering the same scene. Cameras with a large field of view might be split into several views for easier computer vision processing. For zooming, the configuration needs to be mindful of optical resolution limits, computer vision algorithm resolution requirements, the different sizes of vehicles, and the different behavior of vehicles. For instance, oedestrians and bikes are smaller than trucks and buses and mav reouire more or less magnification depending on the camera setup, lens properties, and actual scene composition. In some cases, the path of the vehicle through the scene might need to be captured at the appropriate magnification so that the entire path, or only part of the path, is in view. In other cases, multiple cameras may cover the same scene, so tradeoffs between resolution and occlusion issues need to be determined.

[0006] For all of these cases, the user’s primary concern is typically to figure out what they want to count, actuate, or process, but if only a manual process is available, they have a large number of factors to consider, which require a non-trivial understanding of the underlying computer vision algorithms.

SUMMARY

[0007] An automatic camera-based system for traffic engineering and ITS applications is considered to be important in obtaining reliable data and ensuring that vehicles are detected, for example, so as not to sit idle at red lights indefinitely. The following provides a system that is configured to assist with, and/or eliminate the need for, a user to understand the internals of the computing system by assisting and/or fully automating the video configuration process. In this way, for example, the system may only require the user to map what events they want the system to output, not necessarily how they want the system to generate the events. Semi-automated methods are also enabled in the system described herein.

[0008] In one aspect, there is provided a method of refining a configuration for analyzing video, comprising: deploying the configuration to at least one device positioned to capture video of a scene; receiving data from the at least one device; using the data to automatically refine the configuration; and deploying a refined configuration to the at least one device.

[0009] In another aspect, there is provided a method for automatically generating a configuration for analyzing video, comprising: deploying at least one device without an existing configuration; running at least one computer vision algorithm to detect vehicles and assign labels; receiving data from the at least one device; automatically generating a configuration; and deploying the configuration to the at least one device.

[0010] In yet another aspect, there is provided a method of semi-automatically generating a configuration for analyzing video, comprising: obtaining video content to be analyzed; applying at least one automated computer vision technique to the video content to automatically generate at least one track; enabling, via a user interface, entrances to and exits from an intersection recorded in the video content to be identified; performing automated track assignment and, if necessary, automated track clustering to generate a movement template; and outputting the movement template..

[0011] In yet another aspect, there is provided a method of automatically splitting a video view, comprising: applying a view fitting method to a video to find a best view projection from a set of configuration elements; determining a score and corresponding view projection parameters for any set of configuration elements and any available views from the video; formulating a large scale optimization problem to assign configuration elements to views; and identifying feasible and/or maximum view fitting scores per view.

[0012] In yet another aspect, there is provided a method of automatically assigning cameras, comprising: obtaining a configuration with a plurality of cameras; applying one or more camera-dependent properties to the configuration elements; and assigning the configuration elements to a camera with the best view of that element.

[0013] In yet another aspect, there is provided a method of automatically assigning a camera, comprising: detecting an incorrect vehicle track; applying an optimization formula to determine a camera parameter error; and determining one or more camera calibration parameter changes.

[0014] In other aspects, there are provided a computer readable media and system(s) for performing the above methods.

BRIEF DESCRIPTION OF THE DRAWINGS

[0015] Embodiments will now be described with reference to the appended drawings wherein:

[0016] FIG. 1 is a block diagram of a system for a traffic video analytics system.

[0017] FIG. 2 is a schematic diagram of a traffic video analytics system connecting to a series of intersections.

[0018] FIG. 3 is a block diagram of a video capture device located at an intersection.

[0019] FIG. 4 is a block diagram of an intelligent traffic system (ITS).

[0020] FIG. 5 is a block diagram of a configuration platform that can be used by or within an ITS.

[0021] FIG. 6 includes a series of heat map images generated from a traffic video.

[0022] FIG. 7 is a heatmap showing vehicle movements through an intersection. [0023] FIG. 8 is a flow chart illustrating computer executable operations performed in refining a video configuration.

[0024] FIG. 9 is a flow chart illustrating computer executable operations performed in generating a new video configuration from device data.

[0025] FIG. 10 is a flow chart illustrating computer executable operations performed in automatically refining a video configuration.

[0026] FIGS. 11 to 14 illustrate vehicle tracks before and after refinement using an automatic configuration process.

[0027] FIG. 15 is a flow chart illustrating computer executable operations performed in automatically generating a new video configuration.

[0028] FIG. 16 is a flow chart illustrating computer executable operations performed in inferring boundaries of an intersection from track data in the process shown in FIG. 15.

[0029] FIGS. 17 to 20 illustrate vehicle tracks, intersection entrances and intersection exits identified using an automatic configuration process implemented for a new configuration.

[0030] FIG. 21 is a flow chart illustrating computer executable operations performed in applying a semi-automated configuration process.

[0031] FIG. 22 is an image showing automatically generated tracks in a video.

[0032] FIG. 23 illustrates the image of FIG. 22 with a first user-labeled approach that is automatically associated with one or more tracks.

[0033] FIG. 24 illustrates the image of FIG. 22 with a second user-labeled approach enabling automatically clustered and labelled tracks.

[0034] FIG. 25 illustrates the image of FIG. 22 with a complete set of user-labeled approaches with tracks being shown assigned to movements as the user configures the application.

[0035] FIG. 26 illustrates the image of FIG. 22 clustering and template creation applied to an intersection with all approaches labelled.

[0036]

[0037] FIG. 27 is a flow chart illustrating computer executable operations performed in an automatic camera view splitting process. [0038] FIGS. 28 and 29 illustrate a manually configured five-view configuration assigned to in a nine-view configuration.

[0039] FIG. 30 is a flow chart illustrating computer executable operations performed in an automatic camera assignment process.

[0040] FIG. 31 is a flow chart illustrating computer executable operations performed in a camera calibration process.

[0041] FIG. 32 illustrates an example of an orientation map.

DETAILED DESCRIPTION

[0042] Turning now to the figures, FIG. 1 illustrates a video-based system 10 for monitoring, analyzing, and/or controlling elements of or in a monitored area 12, e.g., a traffic intersection using video captured at or near the monitored area 12. A video capturing device 14, such as a camera or other device having a camera captures video to generate video data 16 associated with the monitored area 12. The video data 16 can be locally stored by the video capture device 14 (e.g., using an internal or externally coupled storage device). The video data 16 can also be transmitted over a communication channel to a cloud system, e.g., a processing server, network infrastructure, etc. In this example, the cloud system is a cloud-based intelligent traffic system (ITS) 20. The communication channel between the video capture device 14 and the ITS 20 can include a wired, wireless, or manual delivery channel capable of transporting the video data 16 from the image capture device 14 to the ITS 20 for subsequent usage and/or processing. For example, a cellular network can be used for wireless transmission, a fiber optic network can be used for wired transmission, and a portable media device (e.g., universal serial bus (USB) drive) can be used for manual transportation of the video data 16.

[0043] The ITS 20 can include a configuration platform 22 used to create and/or improve video configurations utilized in analyzing video captured by the video capture device 14, which can be performed by the ITS 20 or another system. The configuration platform 22 can also communicate with the video capture device 14 to push out video configuration data 18.

[0044] FIG. 2 illustrates a wider view of a traffic monitoring and/or control system in which a cloud-based ITS 20 and configuration platform 22 are in communication with a number of intersections 12, each having an intersection system (IS) 24. Each IS 24 in this example can include one or more video capture devices 24 for capture video associated with the corresoondino intersection 12. The connectivitv shown in FIG. 2 enables the configuration platform (CP) 22 and ITS 20 to bi-directionally communicate with the ISs 24 and to send or receive data to/from the ISs 24, e.g., video data 16 and configuration data 18 as illustrated in FIG. 1.

[0045] FIG. 3 illustrates an example of a configuration for the video capture device 14. In this example, the video capture device 14 includes an image sensor 30 for capturing a series of images to generate the frames of a video, and a local processing module 34 for performing local processing functions such as object of interest extraction, compression, etc. The local processing module 34 can also use a video data interface 36 to send video to the ITS 20 via a wireless network 38. As shown in FIG. 2, the video capture device 14 can also include a data interface 40 for receiving communications and/or data from, among other things, the ITS 20 and configuration platform 22. It can be appreciated that the video data interface 36 and data interface 40 are shown as separate components for illustrative purposes only and both modules and/or functionalities can be implemented using a single device, e.g., a transceiver configured to wirelessly transmit video data and to wirelessly receive configuration or update data via one or more wireless networks 38.

[0046] FIG. 3 also includes a machine learning platform 42 that can be utilized to have the configuration data 18 generated by the configuration platform 22 updated and/or refined as data is captured and processed by the system 10. The machine learning platform 42 can be used to take advantage of a validation stage in a traffic analytics system to provide meaningful data in a database for determining the accuracy of the tracks and objects detected in a video. This meaningful data, processed on a large scale, allows the machine learning platform 42 to train the analysis system to which it is coupled towards better classifiers for the objects being detected.

[0047] FIG. 4 illustrates a configuration for an ITS 20. In this example, the ITS 20 includes or otherwise has access to the configuration platform 22, which includes a configuration user interface 44 that can be used by personnel to create, refine and deploy video configurations to the IS 24 without necessarily having an understanding of the underlying algorithms used to detect objects of interest in the video data 16. The configuration platform 22 can have access to a datastore of video configurations 48 that can be deployed to devices and refined over time. The configurations 48 generated by the configuration platform 22 can also be used by one or more other ITS operations 46 such as traffic control, traffic analytics, traffic or infrastructure planning, or other applications that use the video data 16. [0048] The video data 16 that is received from the video capture device(s) 14 is received by a data streaming module 52 that is configured to provide a communication interface between the ITS 20 and the wired and/or wireless networks used by the ISs 24 to stream or otherwise send or transport the video data 16 to the ITS 20. The data streaming module 52 stores the video data 16 in a traffic data repository 50 for use by the ITS operations 46 and configuration platform 22. The ITS 20 in this example also includes a machine learning module 54 to locally access and analyze the video data 16 from the data repository 50 for and/or with the machine learning platform 42. It can be appreciated that the machine learning platform 42 and machine learning module 54 are shown separately as local- and remote-based elements for illustrative purposes and can be arranged in different configurations in order to perform machine learning on or using the video data 16 in the traffic data repository 50.

[0049] The configuration platform 22 is shown in greater detail in FIG. 5. The configuration platform 22 can include the configuration user interface 44 to enable users to interact with the configuration platform 22, e.g., to create or refine a video configuration. The configuration platform 22 can also include a configuration data interface 62 to interface with the datastore of configurations 48. The configuration platform 22 is used to create and/or refine a video configuration in a partial, semi- or fully-automated fashion. This can be done using an automatic configuration process 60 and/or semi-automatic configuration process 61 that can be directed by, approved by and controlled by the user. The user and/or the system 10 can also use the configuration platform 22 to execute an automatic camera view splitting process 64, an automatic camera assignment process 66 and a camera calibration process 68. Each of these processes can be considered a system “configuration” that can be generated and deployed to the ISs 24. The configuration platform 22 is therefore included in the ITS 20 or is otherwise provided in the system 10 to use data streamed by the video capture devices 14 to create or improve configurations. That is, the system 10 described herein uniquely leverages data gathered from devices to improve video and camera configurations and settings. The system 10 can also be configured as shown in FIG. 2 to enable the ITS 20 or configuration platform 22 to deploy updated configurations to devices in the field such as the ISs 24.

[0050] To determine the best positioning and locations where vehicles and people stop in the scene, heatmaps and trackmaps can be used. Referring now to FIGS. 6 and 7, example heatmaps are shown. The heatmaps are cold/hot views of frequent locations that vehicles or people travel within the frame of a video. The heatmaps can be used to see the vehicle or pedestrian paths and also the amount of time an object stays in a location. These heatmaps provide information on exactly where vehicles stop on the roadway so that a detection zone can be created through automation or manual efforts. Using the gradient information contained in the image and/or from the tracks, they also provide vehicle movements that may not be obvious without this data initially. Often, manual configurations fail to annotate driveways or even subdivision entryways so having a heatmap calls attention to regions where there is significant data but no corresponding movement. These movements can be automatically generated from the heatmaps and trackmaps. The heatmaps can even provide areas where pedestrians are waiting and, through automatic configuration, can be used to trigger a crosswalk or even simply an alert or count of people walking in dangerous areas in a city. For example, a heatmap for a path can be used by a transit station to count pedestrians entering in unintended areas of the station and even prompt a redesign of a platform based on the paths pedestrians take. That is, the heatmaps and trackmaps can provide a mechanism to automatically generate these configurations and to identify paths that the platform or roadway designer did not initially consider.

Automatic Configuration

[0051] The automatic configuration process 60 shown in FIG. 5 can be used to perform a data-driven configuration refinement process as well as a data-driven configuration creation process. Referring to FIG. 8, a configuration refinement process is shown. There are several use cases for refining an existing configuration. For instance, if the scene changes over time, the configuration can adapt to changes in how vehicles behave or even changes due to road conditions, road obstructions, construction, or permanent layout changes. Furthermore, the system 10 can provide different configurations depending on the vehicle type. Trucks, for instance, might follow a different path to take a right turn than a passenger vehicle. From these configurations, it is also possible to create informed vehicle models, such as a typical turning radius, exactly where vehicles stop when entering an intersection, or stopping distance for vehicle types. These stats and values are not only useful for configuration refinement, but also for safety analytics and other analyses that can be conducted downstream of the configuration platform 22, e.g., as part of an ITS operation 46.

[0052] As shown in FIG. 8, the data-driven configuration refinement process begins at 100 by deploying a configuration into the field, by providing the configuration to the video capture device(s) 14. A “configuration” provides a way to tell the machine processing algorithm what the algorithm needs to look for in the scene. A configuration can tell a device deployed at an intersection to process streamed video, live, and map results to actuation channels in the traffic controller; or a configuration can instruct the algorithm to process a video file offline and map the results into a database that can be queried for historic values. In both cases, the user specifies regions of interest and what they want the algorithm to do. The configuration can ask the algorithm to count all vehicles turning right, driving through, or turning left. The configuration can detect and actuate vehicles as they drive up and stop at an intersection, or pedestrians as they gather on the sidewalk to cross the street. Configurations can include interactions between cyclists and road vehicles and measure things like speed or perform various safety analytics. The important pieces are to ensure that the spatial locations of the configuration are correct, because if a left lane is not drawn where vehicles make a left turn, all of the data and downstream analytics are not going to be useful. The assisted and fully automated configuration method ensures that the regions of interest are specified using data to get the most accurate spatial setup for a scene. Furthermore, the tooling also provides a mechanism to ensure that movements or zones of interest are not missing by making it very apparent when there is vehicle behavior, but no corresponding region of interest. For a device deployed at an intersection, the configuration can be stored as a file on the device. For an offline video file application, the configuration can be stored as a file alongside the video or stored in a database or in another representation or format.

[0053] At 102 the configuration platform 22 receives data from the device(s) 14 and automatically refines the configuration at 104. This can be done by using the automatic configuration process 60 in a refinement mode. The result produces a refined configuration, which can be deployed back into the field at 106. Optionally, the process can be iterated at 108 to further and continually refine the configuration over time. That is, the configuration refinement process can be repeated as many times as desired using the new data obtained from the automatic configuration process 60. Using this feedback, the configuration can continue to improve and adapt to changing traffic conditions. Moreover, the refined configuration can be used in one or more downstream data consumption operations at 110, for example, a user can perform a safety analytics study on the results from a refined configuration, a user can collect turning movement counts with the configuration, an intersection can actuate traffic lights based on presence zones created from the configuration, a traffic engineer can redesign an intersection based on where vehicles stop and start, or a railway station can redesign the platform based on the paths pedestrians take, to name a few. [0054] Referring now to FIG. 9, the automatic configuration process 60 can also be used in a creation mode to create a new configuration. In many cases, a configuration may not exist beforehand. For example, a user may have just installed a system, want to get up and running as quickly as possible, and may want the system to simply “run” without any intervention whatsoever. It is also possible that the user does not know how drivers behave in a specific region, that different environments and regions have very different driving patterns including differences in stopping areas, how much drivers cut their turns, and the presence and density of pedestrians and cyclists, to name a few. From experience, there are also many cases where a configuration is set up with driving assumptions and only afterwards additional movements, some illegal, are discovered and play a large role in the results of a traffic study. A fully automated data-driven configuration can provide an initial set of configuration elements that the user can later map to downstream analytics or actionable items.

[0055] In this example, video capture devices 14 can be deployed without a configuration at 120. The devices 14 can be configured to run one or more computer vision algorithms to detect vehicles and assign labels to each vehicle indicative of a classification at 122 to generate data for the configuration platform 22. The configuration platform 22 receives data at 124 and automatically generates a configuration at 126. This can be done by using the automatic configuration process 60 in a creation mode. The result produces a video configuration, which can be deployed into the field at 128. Optionally, the process can be iterated at 130 as discussed above, to further, and continually, refine the configuration over time. Moreover, the refined configuration can be used in one or more downstream data consumption operations at 132 as discussed above.

[0056] Further detail for an example of an automatic configuration refinement process as implemented at 104 (see FIG. 8), is shown in FIG. 10a. At 140 the computer vision data is obtained and at 142 vehicle tracks are created from the computer vision data. The vehicle tracks can be created using any existing tracking algorithm, such as a Kalman filter, a Hungarian matching algorithm, or a convolution neural network (CNN). Tracks can then be clustered at 146 to represent desired movements (e.g., left turn, S-to-N-bound through movements, etc.). Existing clustering algorithms, such as K-means can be used at 146. As shown in FIG. 10a, meaningful features 144 for the clustering algorithm can be generated ahead of time using classical computer vision techniques. Such meaningful features can be engineered features or machine learned features paired with a clustering algorithm that successfully clusters tracks into movement groups. [0057] Referring now to FIG. 10b, some engineered features that work well for movements and that can be represented as splines include: (i) first point on the path, (ii) last point on the path, and (iii) largest distance of a point on the path to the line segment defined by the first and last points (i), (ii). These features can capture directionality, curvature for turns and u-turns, and lane separation of movements going in the same direction. A k- means clustering algorithm using a Bayesian Gaussian Mixture model is one of many ways to find clusters of movements that represent a mappable logical movement - the mixture model is suitable because it works well with overlapping clusters that typical for more than one lane of traffic in the same direction. More generally, a number of unsupervised clustering methods and models can be applied in other applications

[0058] For each cluster, further clustering can be applied at 148 to separate a movement into individual lanes, if desired. For example, a through movement may have three lanes. As with the clustering at 146, existing clustering algorithms can be used and meaningful features can be generated ahead of time using classical computer vision techniques, and can include engineered features and/or machine learned features. This generates an initial configuration 150.

[0059] Using the initial configuration 150, each cluster can be mapped and assigned to an element in the configuration, where possible at 152. For example, the initial configuration 150 may have three different left turns, the left turn that is “closest” to the tracks in a cluster is mapped to that cluster. Some clusters may not have corresponding elements in the initial configuration, these can result in alerting the user to something that is misconfigured or missing (intentionally or otherwise) from the configuration. The measure of a configuration element to a cluster track’s “closeness” can be adapted by the system 10 for the traffic domain.

[0060] “Closeness” can be defined as the residual from a given loss function. Given an ensemble of paths, sampled points for each vehicle path from real-data, a model for the movement or zone can be defined and arguments for that model can be found that best fit the model to the data. A simple example would be fitting a line through some points. The challenge with these movements is that they are less well defined and that even the sampling process has noise and variability. For instance, points may be missing, so knowing where to start a line can be a challenge. Also, a line can be a very poor choice as a model in this domain. That being said, a least squares optimization methodology can still be useful using a spline, such as a b-spline, or a fourth-order polynomial as the model. To make this problem tractable, theory and experimentation lead to the choice of arguments for a spline that best fits an ensemble of paths, not points. For vehicle movements in the traffic domain, a start-point (xO, yO), a midpoint (x1 , y1), and an end-point (x2, y2) where selected as the arguments for an optimization system, with an internal cubic spline model fit to those arguments, severe cost-injection (with gradients) imposed if any sampled point was beyond the start and end of the cubic splines, and the density of the ensemble points were used in a Frechet distance formulation to determine the cost function and residuals. This formulation is both used to measure the “closeness” of a given movement and also to calculate the best fitting movement from data. Using this process to generate movements from data can be easier than having the user take their best guess at where vehicles appear and travel through the scene and can be dynamically adjusted over time as new data comes in. If construction occurs, new data can impose change to the configuration file as vehicles travel different paths around construction and obstacles.

[0061] Once the initial configuration elements are mapped to the cluster tracks, the configuration elements can be manipulated at 154 to improve how well they represent the tracks. For example, the configuration element can be a spline model, which has been proven to be effective. The configuration element can also be a more complicated model such as a probability field, a density model, or a multi-modal composite of any of the above. Existing optimization methods, such as spline fitting, can be used to improve the representation. For insufficient data, this configuration element manipulation operation at 154 may do nothing and keep the initial configuration. This choice of action can be later reported to the user if desired.

[0062] Optionally, at 156, the user can be given an option to review and approve the proposed changes from the automation steps above. For example, the user can be presented with a before and after view, and without requiring any knowledge of the underlying system, may choose to accept the recommended configuration. At 158, the configuration can then be confirmed for deployment onto the device(s) 14. For deployment, validation can occur if it is desired to conduct A/B testing and, when deployed, new data can be generated using the automatically refined configuration. The A/B testing allows the user to try out a new configuration and compare it against an existing one. If the new configuration produces a more accurate representation of the world, then the new configuration replaces the old and is activated. If the old configuration is better, then the user can decide if they want to keep it entirely or replace it with elements of the new configuration. This step provides a “sanity” and data analytics measure of the benefit of the data-driven configuration. It also provides a check to ensure that the user has mapped the configuration meaningfully and labelled data correctly.

[0063] FIGS. 11 and 12 illustrate track points and configuration tracks before and after the refinement process. Before, in red (example identified by numeral 106a), are set up manually by the user by having them look at the intersection and make their best guess. The after, in blue (example corresponding track identified by numeral 106b), show how the initial red movements deviate to best fit the data obtained from the intersection. FIG. 13 illustrates a camera view before and FIG. 14 the camera view after the configuration has been refined. FIG 14 illustrates how well the reconfigured approaches match some of the underlying data for vehicles. Compared to FIG 13, FIG 14 matches a heatmap representation of the image much better than the initial configuration in FIG 13. All of the “after” configurations in these figures were generated by refining the initial ones provided by the user. The result is that the user can create an initial one (if desired) and have the computer refine it based on data using the same mappings (thru, left, right, northbound) that the user initially defined.

[0064] Further detail for an example of an automatic configuration creation process as implemented at 126 (see FIG. 9), is shown in FIG. 15. At 170 data that has been received from the device(s) 14 deployed without a configuration is obtained, which data detects and tracks all vehicles and labels each vehicle with a classification. The tracks are clustered at 172 such that each cluster represents a desired movement (e.g., left turn, S-to-N-bound through movements, etc.). For each cluster, further clustering can be applied at 174 to separate a movement into individual lanes, if desired. For example, a through movement may have three lanes. The boundaries of an intersection and roadway are then inferred from the track data at 176, which generates a set of entrances and exits from the intersection 178. Further detail concerning inferring boundaries is provided below.

[0065] The clustering process can occur again at 180, if needed, using the information about entrance and exit locations 178 to improve groupings. The configuration elements can be created from each cluster as a model at 180. For example, the configuration element can be a spline model, which has been proven to be effective. The configuration element can also be a more complicated model such as a probability field, a density model, or a multimodal composite of any of the above. Existing optimization methods, such as spline fitting, can be used to fit the track data to the spline, or other model. For insufficient data, this configuration element creation operation 182 can create a new element, but also tag that element as having little data so that a user can later determine if they want to map it to something downstream. [0066] Optionally, at 184, the user can be provided with an option to perform a manual approval of the proposed changes from the automated steps described above. The created configuration can then be confirmed for deployment at 186 to be deployed onto the devices 14 as discussed above in connection with FIG. 9.

[0067] Further detail for operation 176 in which boundaries of an intersection are inferred from the track data is illustrated by way of example in FIG. 16. At 190 the primary directions of the tracks are collected, for example Northbound, Southbound, North- Eastbound, etc. The number of entrances and exits are then determined by the primary track directions at 192. The entrance and exit locations can be determined at 194 by real-world constraints on the tracks. For example, “forks” are entrances that have two or more paths starting at that direction and ending in at least two different directions. Merges are exits that have two or more paths ending in the same direction but starting in at least two different directions. If no turns are present in an intersection, entrances and exits can be determined by where the vehicle tracks cross and locations where vehicles idle (for instance at stop bars). Heuristics can also be applied, such as those considering that entrances and exits on the same leg are often collinear, but not always as in the case of a slip lane. Common intersection templates can also be used for regularization. The intersection boundary will include all the entrances and exits along the boundary. At 196 the entrance(s) and exit(s) along each intersection boundary are identified for movement clustering at 180 as shown in FIG. 15.

[0068] FIGS. 17 and 18 illustrate track points, entrances, exits, and movements for two different configurations that have been created using the process detailed above. FIG. 19 illustrates a manual configuration and FIG. 20 a fully automated configuration using the fully automated process described above. Unlike FIGS. 11 and 12, FIGS 17 and 18 did not require any user input at all. With this process, tracks can be generated without initial user input and the configurations can be completely and fully automated without requiring any user input. It may be noted that multiple lanes in the same direction are also discovered and annotated without user input. FIG. 13 is reproduced as FIG 19, alongside FIG 20. Unlike FIG. 14, FIG. 20 is entirely automated from scratch based on the data available. One thing to note is that when generating the configuration for FIG. 20, there were no bikes during this sample so a bike-only lane was not generated in this case, as it appears in FIG. 19. Once the data is available, however, the bike lane would appear. Whereas FIG. 14 kept the initial and manual bike lane in place, there was no evidence to support having it in FIG. 20 thus it was not automatically generated. This illustrates an advantage of refining a manual configuration rather than creating one entirely from scratch. There are, however, cases where the manual configuration does not have a corresponding movement, but the fully automated one does. Ultimately with enough data, the fully automated process should capture all of the movements.

Semi-Automatic Configuration

[0069] As shown in FIG. 5, the configuration user interface 44 can also access a semiautomatic configuration process 61 , which can be used such that the automated configuration output is used in a semi-automated user interface. The challenge with existing configurations is that the user is commonly asked to configure a scene for video processing before the video runs. As established, this is typically error prone if the user misses vehicle movements or does not configure where the vehicles or people actually move. In other cases, the user may not want certain movements counted, but may not know without looking at the video, which can be very time consuming.

[0070] The semi-automated configuration described herein improves configuration accuracy and allows the user to label movements after the video processing runs. Referring to the flowchart in FIG. 21 , first, a live or recorded video obtained at step 200 is processed through an automated computer vision (CV) algorithm at step 202, which detects, generates, and produces high quality tracks at step 204. In step 204 the algorithm can also estimate the camera position allowing the tracks to be registered to a scaled model, for example in meters, of the world.

[0071] Next, at step 206, when optionally using the semi-automated interface, the user is presented with the track data, and optional camera estimate, and is then able to label the data. Rather than requiring a tedious process requiring the user to draw precise movement templates, the user simply labels the approaches and the automated part of the user interface does the rest. In FIG. 21 this can include automated track clustering, automated track assignment, and this also enables the user to filter undesired tracks as an optional step. A report or other output of the semi-automated output can then be produced at step 208.

[0072] The automated part of the user interface can take the user-drawn zones and associate tracks that either enter or leave those zones. As the user draws additional zones, the automation can immediately update the display so that the user can quickly see tracks that originate from one zone and terminate in another. This provides real-time feedback and interactivity to the user so that they can quickly and effortlessly iterate on their zone placement without any doubts as to what is being counted and what is being excluded. Previously, such a process involved guesswork and the user would typically wait some time for video completion before getting feedback. By processing first without user input, the time from video collection to preparing tracks for user labelling is significantly improved and fully automated.

[0073] Once the user completes all desired approaches, the automated configuration publishes the generated movement templates. These templates can be created by clustering all tracks that originate from and terminate in the same pairs of zones using any standard clustering algorithm.

[0074] Additional post-processing can also occur automatically. With the templates created, the automated part of the user interface can quickly remove outliers, update the estimate of the camera orientation and position, provide different clustering based on object type, and identify potential tracks that are not matched to the template, in the case the user missed them accidentally.

[0075] Rather than drawing zones for the approach entrances and exits, the user could swap them out with line segments. Anything that crosses the line segment could be considered as entering or exiting, more generally passing through, they are of interest. Templates can be readily constructed using the same procedure as the zones.

[0076] The semi-automated configuration can also provide very accurate track to real- world correspondence by asking the user to provide a scale, either through geo registration or by clicking on two image coordinates and specifying a real-world distance. The same procedure above applies, but now also takes into account a more accurate camera position applied on top of the automated estimate.

[0077] This process is further illustrated making reference to FIGS. 22 to 26. Referring now to FIG. 22, the automated CV system can convert the video into tracks 210, and creates an approximate camera configuration so that the tracks are mapped in a common and scaled coordinate system (e.g. meters). These tracks are presented to the user when the video completes, or streamed if desired. As illustrated in FIG. 23, the user labels an approach 212N and, tracks are automatically associated. Next, as shown in FIG. 24, the user labels a second approach 212E, and tracks are automatically “clustered” and labelled.

[0078] With labelled approaches, the user can easily see which tracks are assigned to which movement in real-time, as they configure the application. The clustering and assignment portions are automated. Once all approaches are labelled as shown in FIG. 25, the automated part of the config completes the clustering and template creation. All tracks are then associated with a movement template as shown in FIG. 26 and reported.

Automatic View Splitting

[0079] There are many situations where a single camera has a large field of view and can be split into several views for computer vision algorithm processing. One such example is a hemisphere lens attached to a surveillance camera. The camera, when facing downward, can see the horizon in all directions. A typical computer vision processing algorithm may accept views that are 300 x 300 pixels for efficient processing in real-time; they generally are not efficient on 4k images directly and scaling the 4k down to the 300 x 300 would result in significant object resolution loss. A typical, existing methodology is to split the large image into sub-views, and often will convert the warped looking image from the camera into a perspective projection, which is more characteristic of a “normal” camera.

[0080] For a manual configuration, after the user specifies what computer vision data they want to map downstream, they would need to then figure out how to split the fisheye view into sub-views that work best for the underlying computer vision algorithm. The user would be required to determine the minimum, average, and maximum pixels per meter of each vehicle class as it would move through the predefined configuration elements. For example, a bicycle moving along a right turn may have 30 pixels/m at the start and 100 pixels/m in the middle of the movement. Then, the user would need to assign each of these configuration elements to a view that provides sufficient resolution for that class, not too much and not too little, based on empirical results for a computer vision algorithm. Following the above example, the best bicycle accuracy may be at 50 pixels/m. This problem can be intractable for a typical user with little to no understanding of computer vision.

[0081] The automatic camera view splitting process 64 (see FIG. 5) formulates and implements an optimization method that can find a feasible solution that best maximizes a fit score for each configuration element and each view movement.

[0082] Referring to FIG. 27, at 220 a view fitting method can be applied to find the best view projection from a set of configuration elements. Traditional “fit objects to view” methods find the convex hull of all the object extremity points in a view and then solve the inverse problem of finding view parameters (such as zoom, center-point, and rotation), that maximize the area of the projected convex hull in the view image space. There are many such implementations that previously exist. Using a traditional “fit objects to view” method applied to a set of configuration elements, a score can be generated from a set of criteria and constraints. From a detailed study of a computer vision detection algorithm, the optimal resolution of an object class can be determined, as well as the resolution limits where accuracy no longer becomes acceptable. These resolution limits can be stored in a lookup table and can be used to establish criteria. A more powerful “fit objects to view” method can be implemented using existing mixed-integer program (MIP) optimization methodologies. The resolution constraints per class can be converted into criteria using cost-injection variables that severely penalize invalid constraints, but also provide a gradient for the solver to follow from an infeasible starting solution into a feasible region.

[0083] Statistics for each configuration element, regarding resolution, can be calculated and used to measure the distance from the ideal pixels/m resolution for sampled points near the configuration elements. This resolution difference can be aggregated for each class using the worst score across the class types along the path and be added into the optimization cost function. Furthermore, the cost function can include other desirable properties, such as how long of a path is required for a sufficient match; rather than requiring the entire convex hull to be visible, one can exclude parts that add little information context in favor of increasing resolution/m. The resulting cost function can include the resolution and behavior terms that correlate with a good view. The view projection parameters (e.g., center, zoom, and rotation) are the parameters for which the MIP attempts to find while optimizing the cost function. Experiments have shown that a simple and existing solver, like Gradient Descent, is able to find the camera projection parameters that achieve the best computer vision accuracy through the optimization formulation above.

[0084] Since the configuration has a large number of requirements, it may not be possible to fulfill them all. A development here is the discovery of a system where fulfilling all of the requirements is not necessary. By focusing on the desired behavioral aspects above, like resolution I m, grouping adjacent lanes, and targeting sufficiently long and short pieces of a movement rather than the whole movement (like the bend in a turn), the entire movement, which may require more resolution than is available for real-time performance, is not needed. Instead, these desired behaviors are encoded into the fitting algorithm, each with a minimum, ideal, and maximum tolerances from an ideal. Though this formulation may be simple in some cases, and existing solver methods can be applied, here are the ideal characters for a given class, do not exceed these deviations or impose a large penalty with a gradient pointing the solver towards the ideal. For the traffic industry problem, some of the features included (i) min I idea I max resolution per meter for each class, (ii) a minimum I ideal / maximum path length for each class based on their size and speed, (iii) preferences to select from one or more cameras based on camera proximity to path and potential occlusions due to lane obstructions, (iv) preferences to capture the movement where unique features, like bends or turns occur, (v) fitting as many points as possible from a zone, (vi) balancing trade-offs to produce a sensible configuration even when a feasible solution cannot be found, the best infeasible solution for the user. An example of a trade-off would be preferring to create reliable detection zones in favor of countable movement paths because the detection zones have real-world actuation consequences

[0085] Using the view fitting function above, a score and corresponding view projection parameters can be determined at 222, for any set of configuration elements and any number of available views. For example, one may wish to find the least number of views to obtain feasible view projection parameters. Or, one may wish to find the most accurate setup given a fixed number of views, as determined by hardware or environment constraints.

[0086] At 224, a large scale optimization problem can then be formulated to assign configuration elements to views, which achieves a feasible/maximum view fitting score 226 for each view. A specific implementation can include a branch and bound algorithm with a modified assignment problem formulation method:

[0087] - No empty views allowed.

[0088] - Can move configuration element to a different view.

[0089] - On each iteration, start with the configuration element with the worst score.

Attempt to move it to other views and select the view that results in the best overall score after the move. If no movement occurred, try moving the configuration element with the second worst score and so on. Continue until maximum iterations have been executed or combinations have been exhausted. The result is always at least as good as the current iteration.

[0090] - Branch and bound because the worst case elements are on the optimization boundaries and are the ones being reassigned. When a worse assignment is discovered, there is no further effort in that direction.

[0091] - While in theory, it is possible to get stuck in a local minimum, in practice and testing, the system did not fail to converge to the best solution.

[0092] FIGS. 28 and 29 illustrate a manually configured five-view configuration to be automatically assigned in a nine-view configuration. The manual setup was not optimal and insufficient to achieve accuracy targets. The automatic view splitting was able to find of all nine-views to hit the accuracy targets. The configuration in FIG 28 has severe problems in that small objects like pedestrians and bikes do not have enough resolution as configured to be detected by the computer vision object neural network model. By combining statistics from available model analytics and applying an automated configuration refinement step, the system was able to create the configuration in FIG 29, which ensures that each movement and detection zone has sufficient resolution and has captured enough of the region of interest such that the computer vision algorithm will accurately detect the objects in the scene.

Automatic Camera Assignment

[0093] There are situations where multiple cameras are used to capture data for the same scene. While they can be overlapping, they do not necessarily need to be. For example, a large intersection may require two cameras to resolve occlusion issues or to have sufficient optical resolution for the computer vision algorithm. Other scenes may have complicated geometry or camera mounting challenges that require different cameras to watch different entrances or exits.

[0094] It has been found that assigning a movement to the best camera is another configuration challenge, which can also be fully automated. Referring to FIG. 30, given a configuration with two or more cameras at 250, the configuration elements can be assigned to one camera with the “best view” of the configuration element at 254 by applying one or more camera-dependent properties to the configuration elements at 252. For example, the camera for which the ground point is closest to the ground points of the configuration elements can be selected as the best camera. The camera that maximizes the resolution for configuration elements can also be selected as the best camera. The camera that has the least occluding other movements between it and a desired configuration element can also be considered the best camera.

[0095] The camera resolution and occlusion parameters can be encoded into a cost function and can extend the automatic view splitting algorithm. Rather than the algorithm operating on all views from the same camera, the algorithm can include camera assignments to each view; in addition to view projection parameters (center, zoom, rotation) an additional “which camera” parameter can be included. The optimization method can then move a view between each of the camera view sets and recalculate the score. Using a branch and bound optimization method the extended automatic view splitting algorithm can now include better resolution options as well as occlusion. [0096] It can be appreciated that other camera dependent properties can be included as well, such as, but not limited to, preference to view vehicles from the side rather than the front due to additional visual features.

Camera Calibration

[0097] In addition to the spatial locations of the configuration elements, the camera calibration can also be automated, again either fully or in an assistant capacity, based on data from the scene. The video contains a lot of information and by creating a mathematical model the behavior of vehicles in the scene can impose self-consistency constraints on the camera making it possible to tune camera calibration parameters. There are many existing methods that do these in various capacities that can be incorporated as part of the system to simultaneously improve the camera position and also improve the spatial locations of the configuration elements.

[0098] As vehicles move through the scene, it is possible to automatically estimate and adjust the camera height and lens parameters. The vehicle physical properties do not change through the camera parameters and can be adjusted to minimize changes to the vehicle length, width, and height, for every single vehicle that moves through the scene. This can be implemented using an online solution as well so that each vehicle provides a tiny amount of correction to the system. In addition, the vehicle track properties are also useful to correct camera parameters. For instance, the nadir and height of the camera, when incorrectly set, will result in a thru-movement becoming curved due to mismatches in the view projection and the vehicle ground paths. Using pattern recognition to determine if the movement is straight or turned, the straight movements can be clustered and used in an optimization formulation that controls the camera parameters to straighten out the ground points. This is particularly useful for highways where the road segment is largely straight. This is less useful for scenes of curved roadways or at atypical intersections. If this algorithm is enabled, it will help improve the camera calibration using data from vehicle tracks.

[0099] Other existing computer vision algorithms can also be included here. This includes items like finding the orientation of the horizon and adjusting the camera to match or finding buildings and straight lines in the scene to help ensure consistency.

[00100] Referring to FIG. 31 , a camera calibration process 68 can include detecting an incorrect vehicle track at 260, applying an optimization formula to determine a camera parameter error at 262, and determining any camera calibration parameter changes at 264. Augmenting Configurations with Additional Data

[00101] Orientation maps are useful for computer vision algorithms to have an initial guess of where vehicles come from. These can be added to the configuration, and do not require users to label directions. While less challenging for a user to label, orientation maps provide a way to ensure that the positions where vehicles enter are consistent with the data, e.g., an inbound configuration element also has data that show vehicles entering the video in those zones. The use of object detection and tracking can provide orientation as well as other existing computer vision solutions like optical flow.

[00102] FIG. 32 illustrates a possible orientation map, where the vehicle direction can be visualized with small directional arrows. The entrance and exit are further emphasized through coloring of red and black, while the underlying data is simply a directional angle at each position. While this happens to be a pixel based orientation map, the data structure can be any existing type, like a polygon with a direction of travel assigned to it. The main purpose is to use data like this in addition to the above to further assist the user in configuring an intersection.

Modular Lane Finding Algorithms

[00103] Existing literature has a number of algorithms that segment the scene to find lanes. These algorithms can also be integrated into this system. The above algorithms were created specifically to solve a domain specific problem. There are other algorithms that can contribute to further refine configurations, camera parameters, and view parameters.

[00104] For simplicity and clarity of illustration, where considered appropriate, reference numerals may be repeated among the figures to indicate corresponding or analogous elements. In addition, numerous specific details are set forth in order to provide a thorough understanding of the examples described herein. However, it will be understood by those of ordinary skill in the art that the examples described herein may be practiced without these specific details. In other instances, well-known methods, procedures and components have not been described in detail so as not to obscure the examples described herein. Also, the description is not to be considered as limiting the scope of the examples described herein.

[00105] It will be appreciated that the examples and corresponding diagrams used herein are for illustrative purposes only. Different configurations and terminology can be used without departing from the principles expressed herein. For instance, components and modules can be added, deleted, modified, or arranged with differing connections without departing from these principles. [00106] It will also be appreciated that any module or component exemplified herein that executes instructions may include or otherwise have access to computer readable media such as storage media, computer storage media, or data storage devices (removable and/or non-removable) such as, for example, magnetic disks, optical disks, or tape. Computer storage media may include volatile and non-volatile, removable and non-removable media implemented in any method or technology for storage of information, such as computer readable instructions, data structures, program modules, or other data. Examples of computer storage media include RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by an application, module, or both. Any such computer storage media may be part of the vehicle capture device 14, ITS 20, configuration platform 22, or machine learning platform 42 any component of or related thereto, or accessible or connectable thereto. Any application or module herein described may be implemented using computer readable/executable instructions that may be stored or otherwise held by such computer readable media.

[00107] The steps or operations in the flow charts and diagrams described herein are just for example. There may be many variations to these steps or operations without departing from the principles discussed above. For instance, the steps may be performed in a differing order, or steps may be added, deleted, or modified.

[00108] Although the above principles have been described with reference to certain specific examples, various modifications thereof will be apparent to those skilled in the art as outlined in the appended claims.