140 likes | 246 Views
4.0 Detector Analysis. Russ Bobbitt bobbitt@us.ibm.com 11/3/11. Face Tracker not the Bottleneck (City Surveillance). Test Videos. Face Tracker not the Bottleneck (People Search). Test Videos. Live Simulation - Cost of Adding Detectors.
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).