Download
1 / 14
140 likes | 259 Vues
This analysis focuses on improving the efficiency of face and vehicle detectors within city surveillance systems. It evaluates the performance of the Face Tracker, Vehicle, and Pedestrian Detectors through live simulations, examining their impact on processing resource consumption. By running tests on increasing numbers of engines, the study aims to identify cost-effective strategies for detector integration. Additionally, it discusses the significance of maintaining detection accuracy while enabling flexible operational modes. The findings can guide future improvements in surveillance technology.
E N D
4.0 Detector Analysis Russ Bobbitt bobbitt@us.ibm.com 11/3/11
Live Simulation - Cost of Adding Detectors • Run Increasing # of engines in increments of 2 (1,3,5,7,…) processing Hawthorne video source for 7500 frames @ 15fps (~8.33 minutes). • Run with and without new detectors (e.g., City Surveillance vs. City Surveillance + Vehicle Detector). • Note: For Vehicle/Pedestrian, Cameras are low-activity scenes and are not ideal camera views for detectors – this should make the detectors less expensive. • Measure CPU consumption using Windows Performance Counters
People Search Summary • Not a priority to replace Face Tracker in People Search profile with something less expensive. • Face Detector already performs well and there are accuracy expectations. Probably not worth investing effort to make it less expensive (at the cost of accuracy) • Can always run all attribute detectors in People Search, whether they are needed or not. Can potentially increase # of engines by a small margin by disabling some detectors, but may not be worth development effort to allow user to disable them.
Vehicle/Pedestrian Detector Summary • Adding Vehicle or Pedestrian Detector to an existing engine is a significant cost and should be considered carefully. • Pedestrian Detector is particularly expensive. Is this expected? • Still need a sparse tracker in CFT to implement “detection only mode” Options to speed up detectors • Do nothing. • Find better tuning by changing # of cascades, threshold bias, step, step resolution, min/max object size. However, labeling and quantitative evaluation will be necessary. • Change detection framework to only run when necessary (e.g., see last slide) • Code optimization
Tracker Switching • Tracker takes either BGS or detection bounding boxes as input – but not both at same time. • Using cues from BGS and detector, a new “switcher” decides which mode is appropriate. • Switcher is conservative so that switching frequency is low. • Implemented as static library in tracker. Main tracker code will not change very much.
Alternatives to Switching • Only Detection Only: Whenever detectors are added to an engine, only take detection bounding boxes as tracker input. How often will this be a good idea 24/7 for a given camera? • Multiple Inputs: Tracker considers BGS and detection bounding boxes at the same time. Difficult problem; current blob carving approach needs work. • Switching: Tracker either considers BGS or detection bounding boxes, but not both at the same time. A switcher decides which mode. In terms of tracking, detectors may have small impact on many cameras (i.e., always in BGS mode).
