1 / 14

4.0 Detector Analysis

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.

tadita
Télécharger la présentation

4.0 Detector Analysis

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 4.0 Detector Analysis Russ Bobbitt bobbitt@us.ibm.com 11/3/11

  2. Face Tracker not the Bottleneck (City Surveillance)

  3. Test Videos

  4. Face Tracker not the Bottleneck (People Search)

  5. Test Videos

  6. 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

  7. Live Simulation - Vehicle Detector Results

  8. Live Simulation - Pedestrian Detector Results

  9. Live Simulation - People Search Results

  10. 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.

  11. 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

  12. 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.

  13. 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).

  14. On Demand Detection

More Related