AnonVision
A privacy-critical computer vision system designed to enforce human visibility boundaries in sensitive visual media. Built for workflows where identity exposure constitutes real-world harm.
"I need to protect confidential sources in protest photos but keep the journalist visible."
— User Research Participant
Selective anonymization exists because privacy is not binary. In journalism, legal review, and research contexts, certain individuals must remain identifiable while others require protection. This creates a control problem: how do you give humans granular authority over algorithmic identity decisions?
The whitelist architecture is a safety decision. A blacklist model ("anonymize these known faces") fails unsafe, if recognition fails, a protected identity is exposed. A whitelist model ("protect these known faces, anonymize everyone else") fails safe, recognition failure results in anonymization, preserving privacy by default.
Offline CPU inference is not a performance constraint, it is a trust boundary. No network egress means no data exfiltration risk. Deterministic execution means reproducible audits. This system was designed for environments where the cost of a false negative is measured in human safety, not user metrics.
- Role Vidual Systems Designer & ML Engineer
- Timeline Sep 2025 – Present
- Tech Stack Python, OpenCV, YuNet DNN, ONNX Runtime, Tkinter
- Constraints CPU-only, Offline, Deterministic
- GitHub View Repository →
Overview
AnonVision solves a systems architecture problem: how do you build a face anonymization pipeline that is deterministic, auditable, and fail-safe, without requiring cloud infrastructure, GPU hardware, or network connectivity?
99%+
Detection Accuracy (Frontal)
CPU
Deterministic Inference
0
Network Dependencies
100%
Replay Reproducibility
Architectural Guarantees
Deterministic Pipeline: Same input image produces identical output across runs. No floating-point variance from GPU execution. Critical for audit trails and legal reproducibility.
Trust Boundary Enforcement: All processing occurs locally. No image data crosses network boundaries. No external API dependencies post-installation.
Fail-Safe Defaults: System defaults to maximum anonymization. Protection requires explicit user action. Recognition failure results in anonymization, not exposure.
Audit-Friendly Output: Original image preserved until explicit save. All transformations are reversible during session. Output contains no hidden metadata.
System Demonstration
End-to-end workflow demonstration: image ingestion, face detection, selective protection assignment, anonymization application, and output verification.
Problem Landscape
Face anonymization is not a convenience feature. In regulated and safety-critical contexts, it is a compliance requirement with legal consequences for failure.
These users cannot afford false negatives or ambiguous failure modes. A missed face in a protest photo can result in arrest. A visible bystander in research footage violates IRB protocol. An identifiable plaintiff in legal discovery creates liability exposure.
Journalistic Source Protection
Reporters documenting protests, conflict zones, or sensitive investigations must publish visual evidence while protecting sources from identification and retaliation.
Constraint: Selective visibility, journalist visible, sources anonymized. All-or-nothing tools are insufficient.
IRB Protocol Compliance
Institutional Review Boards increasingly mandate face anonymization in published research imagery. Manual pixel editing does not scale and introduces human error.
Constraint: Reproducible, auditable process. Must withstand methodological scrutiny.
GDPR & Privacy Regulation
Biometric data processing under GDPR Article 9 requires explicit consent or lawful basis. Facial imagery in public datasets, marketing materials, or surveillance review creates compliance exposure.
Constraint: Demonstrable anonymization with audit trail. Cloud processing introduces data transfer risk.
Legal Discovery & Surveillance Review
Organizations reviewing security footage or processing discovery materials must protect uninvolved parties while preserving evidentiary value of relevant subjects.
Constraint: Chain of custody integrity. Processing must not introduce artifacts that could be challenged.
Common Requirement
All four domains require the same architectural properties: deterministic output for reproducibility, offline execution for data sovereignty, selective control for nuanced privacy decisions, and fail-safe behavior where system errors preserve privacy rather than compromise it.
Research & Discovery
Detector selection was not an optimization exercise. It was an engineering risk-reduction process. Each candidate was evaluated against privacy-grade requirements where detection failure constitutes identity exposure.
Detector Evaluation: Failure Mode Analysis
Why YuNet Met Privacy-Grade Requirements
Deterministic Execution: ONNX runtime on CPU produces identical output across runs. No GPU floating-point variance. Essential for legal reproducibility.
Single-File Deployment: One .onnx model file. No external dependencies post-installation. Reduces attack surface and simplifies air-gapped deployment.
Bounded Failure Envelope: Known failure cases (extreme angles, small faces) rather than unpredictable degradation. Failures can be documented and communicated to users.
Graceful Degradation Path: Haar Cascade fallback ensures functionality even if ONNX runtime fails. System never silently fails to detect.
Technical Architecture
The architecture is not a feature delivery mechanism, it is a privacy enforcement pipeline. Every design decision optimizes for predictability, auditability, and fail-safe behavior.
Detection Pipeline
Sequential processing with explicit validation at each stage. No hidden transformations.
Anonymization Pipeline
Idempotent operations. Every "Apply" starts from original_bgr.copy(), never from previously modified state.
Engineering Principles
Note on UI Design: The interface is not cosmetic, it is a control surface over a safety-critical ML pipeline. Every button, slider, and checkbox represents a decision point that affects privacy outcomes. Visual feedback (red/green bounding boxes, face thumbnails) exists to make system state observable and human-verifiable before irreversible output.
Operational Envelope
This section defines what the system guarantees, what it refuses to do, and how failure is handled. These are operational constraints, not feature descriptions.
Detection Guarantees
| Primary Detector | YuNet DNN (ONNX) |
| Fallback Detector | Haar Cascade |
| Frontal Accuracy | 99%+ |
| Angled (≤45°) | 95%+ |
| Confidence Threshold | 0.10–0.95 (user-adjustable) |
Anonymization Methods
| Gaussian Blur | Kernel 41–99, 3–10 passes |
| Pixelation | Block size 8–50px |
| Blackout | Solid black fill |
| Region Expansion | 10–60% beyond bbox |
| Edge Feathering | 0–50% gradient blend |
System Constraints (By Design)
Known Failure Cases
Extreme angles (>60°): Detection confidence drops. Mitigated by user-adjustable threshold and manual selection override.
Very small faces (<30px): Below effective resolution. User notified; manual intervention available.
Heavy occlusion (>50%): Partial detections possible. Whitelist model ensures occluded-but-undetected faces are anonymized by default.
ONNX runtime failure: Automatic fallback to Haar Cascade with user notification of reduced accuracy.
Lessons Learned
These are not reflections on what was enjoyable. These are post-mortems on what broke, what was dangerous, and what required redesign to prevent real-world harm.
Blacklist Architecture Was Dangerous
Initial design used blacklist model: "anonymize faces matching this list." This fails catastrophically, if recognition fails, protected identities are exposed.
Fix: Inverted to whitelist model. Recognition failure now results in anonymization. Privacy preserved by default.
GPU Inference Broke Reproducibility
MediaPipe with GPU acceleration produced different outputs on repeated runs. Same input, different detections. This is unacceptable for legal/audit contexts.
Fix: CPU-only execution enforced at startup. CUDA and OpenCL explicitly disabled. Determinism is a feature, not a performance tradeoff.
State Accumulation Caused Silent Corruption
Early versions applied blur to working image directly. Multiple "Apply" clicks accumulated blur. Users could not return to clean state without reloading.
Fix: Idempotent operations. Every "Apply" starts from original_bgr.copy(). Predictable, reversible, auditable.
Ensemble Detection Was Unmaintainable
Attempted to combine Haar + MediaPipe + YuNet for "best of all" detection. Result: debugging hell, inconsistent behavior, impossible to explain failures to users.
Fix: Single primary detector (YuNet) with documented failure envelope. Fallback (Haar) only activates on primary failure, with explicit user notification.
Final System
AnonVision is a production-ready privacy enforcement tool. It is not a prototype or proof-of-concept. It is deployable today in air-gapped environments with no external dependencies.
Predictability: Same input produces identical output across runs, machines, and operating systems.
Reproducibility: Processing parameters are explicit and adjustable. Results can be independently verified.
Offline Trust: No network connectivity required post-installation. No telemetry. No data exfiltration vectors.
No Hidden Behavior: All transformations are visible. User controls every decision point. System state is always observable.
Future Roadmap
Each roadmap item represents risk expansion. New capabilities introduce new failure modes, new privacy attack surfaces, and new architectural constraints.
Near-Term
Video pipeline extension: Exponential privacy risk. Frame-to-frame consistency, temporal tracking, and processing latency introduce new failure modes.
Batch processing: Scaling the threat surface. Automation reduces human oversight. Requires robust logging and spot-check workflows.
Medium-Term
Optional GPU acceleration: Determinism risk. Must maintain CPU fallback and flag non-deterministic execution clearly to users.
Installer packaging: Dependency isolation challenge. Must ensure consistent behavior across distribution methods.
Long-Term
License plates, documents: Different detection models, different failure envelopes, different privacy regulations (PII vs. biometric).
Workflow integration: API exposure introduces authentication, rate limiting, and multi-tenant isolation requirements.
Reflections
AnonVision is not a face-blur tool. It is a case study in building systems where failure modes have real-world consequences.
The hardest problems were not technical, they were architectural. Choosing whitelist over blacklist. Choosing CPU over GPU. Choosing single-detector clarity over ensemble complexity. These are tradeoffs that require understanding not just what a system does, but what happens when it fails.
User research shaped the architecture. The whitelist model came directly from conversations with journalists who explained that "anonymize everyone except me" is fundamentally different from "anonymize these specific people." That distinction is the difference between fail-safe and fail-dangerous.
The most valuable lesson: good architecture is not about predicting the future, it is about making failure predictable, bounded, and recoverable.
Core Capability
I can design and build systems where human safety, privacy, and algorithmic reliability are first-class constraints, not afterthoughts bolted onto feature delivery.