Design the face and license-plate blurring system for Google Street View using a deep object detection model. Street View captures panoramic street-level imagery from cameras mounted on cars, trekkers, and drones, covering millions of miles of roads across 100+ countries. Every captured panorama must be processed to blur all human faces and vehicle license plates before publication, to comply with privacy laws (GDPR in Europe, CCPA in California, and local regulations worldwide). The system must detect faces and plates at varying scales, angles, lighting, and occlusion (a face in a car window, a plate partially covered by snow), process millions of panoramas per day with minimal compute cost, and keep the false-negative rate near zero because a single unblurred face is a privacy violation. At the same time, false positives that blur non-face objects (signs, manhole covers, building facades) degrade image quality and user experience.
How would you design this system? Cover the detection model architecture (single-stage detector vs two-stage detector vs segmentation-based), how you handle the extreme scale variation and small objects, how you generate and augment training data for rare cases (motorcycle plates, faces in helmets), how you balance the false-negative vs false-positive trade-off given the privacy-first requirement, the inference pipeline for processing millions of panoramas per day, and how you monitor and audit blur quality at scale.
The Problem: every panorama hides a handful of faces and plates at 20 to 200 pixels among signs and facades that look like them; miss one and it is a privacy violation, blur too many and the street turns to mush.
Answer
The design is a recall-first single-stage detector run on overlapping tiles of the full-resolution panorama, feeding a fail-closed blur gate that no image can bypass on its way to publication. An FPN-style anchor-free detector with separate face and plate heads scores every 1024 px tile at native resolution, detections are merged with panorama-level NMS, and the threshold is set far below the mAP-optimal point so recall, not precision, is what the model is tuned for. Boxes are dilated before blurring, low-confidence boxes go to a cheap verifier that promotes rather than vetoes, and a stratified human audit plus the user report path close the loop on the misses no model catches. The pivotal calls are tiling instead of downscaling, an explicit blur budget instead of a precision target, and treating the blur job as a publication gate rather than a post-processing step.
(1) Tiled Native-Resolution Input: the 8k by 4k panorama is cut into overlapping 1024 px tiles so a 20 px face is still 20 px when the detector sees it; a 2x upsampled re-crop handles the smallest bucket.
(2) Single-Stage FPN Detector: an FCOS-class anchor-free model with focal loss, separate face and plate heads, and pyramid levels matched to the 16 to 256 px object range.
(3) Recall-First Operating Point: the threshold is chosen from the recall-versus-false-positives-per-panorama curve, with a blur budget (blurred pixel fraction) as the only cap on precision loss.
(4) Blur If In Doubt: boxes are dilated 15 to 20%, overlapping boxes are unioned, and an uncertain band is re-scored by a crop verifier that can add blur but never remove a confident detection.
(5) Targeted Data Program: country-stratified plate labels, hard-negative mining on facades and signs, and copy-paste augmentation for motorcycle plates, helmets, masks, and faces behind glass.
(6) Fail-Closed Batch Gate: a panorama publishes only with a signed blur receipt; stratified human audit and user reports feed misses and false blurs back into retraining.
Figure 1: The publication path: tile, detect, merge, blur generously, and never publish without a blur receipt; the audit loop underneath is what keeps recall honest over time.
Clarify Before Designing:
(1) Scale and Latency: how many panoramas per day and how many pixels each; is publication latency hours or days, which decides whether this is a batch system or a streaming one?
(2) Legal Bar: which jurisdictions and what counts as a face or plate (statues, posters, reflections, partial plates), and is “near zero” a measured audit rate or a contractual guarantee?
(3) Blur Budget: what fraction of blurred non-target pixels per panorama is acceptable before image quality complaints outweigh privacy gains?
(4) Capture Fleet: how many camera generations and platforms (car, trekker, drone) with different resolutions and viewpoints must one model serve?
(5) Data Assets: do labeled faces and plates from earlier campaigns exist, and can already-published blurred imagery be reused as training signal?
(6) Back-Catalog: must a better model reprocess years of published imagery, which changes the compute plan and the rollout policy?
Leave a Reply