PaperlayerView exact revision on arXiv

Source-linked AI summary

3DB: A Framework for Debugging Computer Vision Models

Guillaume Leclerc, Hadi Salman, Andrew Ilyas, Sai Vemprala, Logan Engstrom, Vibhav Vineet, Kai Xiao, Pengchuan Zhang, Shibani Santurkar, Greg Yang, Ashish Kapoor, Aleksander Madry

arXiv:2106.03805v1cs.CVcs.LGstat.ML

TL;DR

Computer vision models can be brittle under distribution shift, while diagnosing failure conditions with existing analyses can require substantial manual effort. 3DB uses photorealistic simulation and guided search to investigate model vulnerabilities, and the authors report that simulation findings correspond to physical-world behavior.

  • Problem

    Vision models can fail under distribution shifts, while the situations and root causes of their brittleness are difficult to characterize and existing analyses often require complex tools and manual work.

    Source: §1 · p. 2

  • Method

    3DB renders realistic scenes and searches user-defined, composable transformations to identify and analyze vision-model failure modes.

    Source: §1 · p. 2

  • Results

    3DB uncovers vulnerabilities across debugging use cases, and its simulation analyses are reported to predict model behavior in the physical world.

    Source: §7 · p. 13

  • Takeaways & Limitations

    The authors encourage the community to build on 3DB to uncover further insights into vision-model vulnerabilities.

    Source: §7 · p. 13

    The authors frame physical validity as a requirement: insights should not depend on simulation artifacts and should hold when models are deployed in the wild.

    Source: §2 · p. 3

Abstract

from arXiv · show

We introduce 3DB: an extendable, unified framework for testing and debugging vision models using photorealistic simulation. We demonstrate, through a wide range of use cases, that 3DB allows users to discover vulnerabilities in computer vision systems and gain insights into how models make decisions. 3DB captures and generalizes many robustness analyses from prior work, and enables one to study their interplay. Finally, we find that the insights generated by the system transfer to the physical world. We are releasing 3DB as a library (https://github.com/3db/3db) alongside a set of example analyses, guides, and documentation: https://3db.github.io/3db/ .

MIT ∗

The footnote marks partial work at Microsoft Research and equal contribution.

MIT ∗

  • The authors note that the work was partially completed while at Microsoft Research and that the authors contributed equally.Source: MIT ∗ · p. 1

1 Introduction

Computer vision models can be brittle under distribution shifts, yet diagnosing when and why they fail is difficult and often labor-intensive. 3DB proposes a unified, simulation-based framework for systematically discovering and analyzing these failures.

1 Introduction

  • Models show sensitivity to rotations, translations, synthetic corruptions, and data-collection changes, but the precise situations and root causes can be hard to characterize [KMF18] [HD19] [KSH+19] [EIS+20].Source: §1 · p. 2
  • Existing failure analyses examine issues such as unfamiliar orientations, misleading backgrounds, and shape-texture conflicts, but often require complex tools, manual work, expertise, and data cleaning [ALG+19] [XEI+20] [AEI+18].Source: §1 · p. 2
  • 3DB uses a 3D simulator and guided search over user-defined, composable transformations to identify and analyze vision-model failure modes.It summarizes performance and vulnerabilities interactively, and supports studying transformation interplay while disentangling individual effects.Source: §1 · p. 2
  • Figure 1 collects examples of vulnerabilities identified by prior in-depth robustness studies.Source: Figure 1 · p. 2
  • 3DB aims to rediscover these brittleness patterns in an integrated manner and compose realistic transformations while keeping their effects disentangled.Source: Figure 2 · p. 2, §1 · p. 2
  • The paper evaluates 3DB through classifier case studies and examines whether simulation-discovered vulnerabilities correspond to physical-world failures.Source: §1 · p. 3

2 Designing 3DB

3DB is designed as a modular framework for diagnosing vision-model failures through photorealistic simulation. Its workflow combines customizable scene transformations, policy-guided search, model evaluation, and dashboard-based analysis.

2 Designing 3DB

  • 3DB is modular, letting users specify transformations, search their space, and aggregate search results; its design aims for generality, compositionality, physical realism, user-friendliness, and scalability.The framework is intended to support varied models, tasks, and parameterizable 3D transformations, and to investigate multiple robustness axes together.Source: §2 · p. 3
  • Physical realism is a design requirement: vulnerabilities should correspond to real-world model behavior rather than simulation artifacts and should hold in deployment.Source: §2 · p. 3

2.1 Capabilities and workflow

  • The workflow starts with 3D object meshes and environments, then defines controls that transform scenes during rendering or images afterward.Source: §2.1 · p. 3, Figure 3 · p. 4
  • A user-specified policy selects scenes from compositions of controls; 3DB renders them and records the vision model’s behavior for analysis.Source: §2.1 · p. 3, Figure 3 · p. 4
  • The dashboard highlights failure-inducing configurations, supports per-object performance inspection, and aggregates trends across objects and environments.Source: §2.1 · pp. 3–4
  • Users can replace or extend controls, policies, renderers, inference modules, and loggers; custom evaluators can add support for other vision tasks and models.The default framework supports classification and object detection, and includes more than 10 control types.Source: §2.1 · p. 4

3 Debugging and Analyzing Models with 3DB

The section applies 3DB to a ResNet-18 classifier using rendered 3D objects and varied scene conditions. The case studies expose sensitivity to backgrounds, texture, orientation, scale, and mug contents, including interactions among factors.

3 Debugging and Analyzing Models with 3DB

  • 3DB case studies used a ResNet-18 classifier and 3D models from 16 ImageNet classes, then varied scene conditions to analyze model behavior.The models were checked in clean settings, rendered in simple poses on white backgrounds.Source: §3 · p. 4

3.1 Sensitivity to image backgrounds

  • Background effects varied by object, and average accuracy on “gray pier” was five times lower than on “factory yard.”Orange and lemon were more background-dependent than tennis ball.Source: §3.1 · p. 5, Figure 4 · p. 5

Analyzing all backgrounds with the “coffee mug” model.

  • For the coffee mug, complex backgrounds were associated with more misclassifications, while clean, distraction-free backgrounds tended to perform best.The model sometimes predicted absent classes, including birdhouse for pond backgrounds and traffic light for sidewalk backgrounds.Source: Analyzing all backgrounds with the… · pp. 5–6, Figure 7 · p. 6
  • The mug classifier was generally accurate at 2x zoom, but that zoom induced failure in the well-lit “kiara late-afternoon” environment.This background-and-zoom interaction reveals a fine-grained failure mode.Source: Analyzing all backgrounds with the… · p. 6, Figure 8 · p. 6

3.2 Texture-shape bias

  • Changing texture reduced accuracy by 90–95% on originally correctly classified images, and predictions usually aligned more with texture than object geometry.The pitcher was a notable exception: its most common prediction across textures was vase.Source: §3.2 · p. 7, Figure 10 · p. 7, Figure 11 · p. 8

3.3 Orientation and scale dependence

  • Accuracy depended on orientation and scale, with orientation sensitivity lower for symmetric objects such as tennis balls and baseballs than for uneven objects such as drills.Surface-visibility accuracy heatmaps also showed that atypical viewpoints adversely affect performance and can suggest testable hypotheses, such as whether mugs classify better from below.Source: §3.3 · pp. 7–8, Figure 13 · p. 9

3.4 Case study: using 3DB to dive deeper

  • For mug views with the interior visible, predictions stayed constant across liquid mixtures at only 20.7% of viewpoints; adding coffee made “coffee mug” more likely.Mixing coffee with water or milk shifted predicted labels toward “bucket” and “cup” or “pill bottle,” respectively.Source: §3.4 · pp. 8–9, Figure 14 · p. 9

4 Physical realism

The authors test whether 3DB’s simulated model vulnerabilities correspond to behavior in the physical world. Across recreated scenes, model correctness agreed 85% of the time, with reliability varying by material.

Motivation

  • The experiment addresses whether insights from simulation reflect naturally arising model behavior rather than artifacts of simulation.The authors frame this as a test of whether 3DB can help understand performance and uncover vulnerabilities on real photos using high-fidelity simulation.Source: §4 · pp. 9–10

Method

  • For each object, researchers recreated five simulated misclassifications and five correct classifications in a physical room, then compared model correctness.The scenes were first roughly placed to match the rendering, then refined with a custom iOS application.Source: §4 · p. 10, Figure 15 · p. 10

Results

  • 85% agreement between model correctness on real photos and synthetic renderings indicates that 3DB’s identified vulnerabilities were physically realizable.The study also found that positive examples in simulation were usually classified correctly in the real world.Source: §4 · p. 10, Figure 15 · p. 10
  • Simpler, non-metallic objects such as the bowl, mug, and sandal tended to show more reliable simulation-to-reality agreement than metallic objects such as the hammer and drill.More precise texture tuning might increase agreement, but the authors note that a more comprehensive study is needed to verify this.Source: §4 · p. 10

5 Extensibility

3DB is designed so users can replace or extend its components. The paper illustrates customization through controls, objectives, external libraries, and rendering engines.

5 Extensibility

  • 3DB’s components can be replaced with built-in, third-party, or custom implementations, supporting customization across four axes.The axes are image interventions, objectives, external libraries, and rendering engines.Source: §5 · p. 11

Custom controls

  • Custom controls let users implement desired transformations, including an occlusion control that could support studies of occlusion effects.The framework’s 3D-space interventions can be less labor-intensive to implement and produce more realistic outputs than image transformations that may introduce artifacts.Source: §5 · p. 11

Custom objectives

  • Users can extend 3DB to analyze tasks beyond its built-in image classification and object detection support, including depth estimation and segmentation.The framework provides corresponding segmentation and depth maps; users can also extend the renderer for additional outputs such as pose-estimation joint coordinates.Source: §5 · p. 11

External libraries

  • External image-transformation libraries can be incorporated into 3DB control pipelines with little effort.The ImageNet-C common-corruptions control is implemented essentially as a single function call to that library.Source: §5 · p. 11

Rendering engine

  • Users can customize or replace Blender, the default rendering backend, to suit different needs for fidelity, ease of use, or performance.The paper illustrates a Blender procedural-sky control for simulating illumination at different times of day; it also describes Mitsuba for accurate simulation and a rasterization backend for real-time performance at the expense of realism.Source: §5 · pp. 11–12

6 Related Work

Prior work studies robustness, synthetic transformations, interpretability, and simulation, but 3DB aims to unify analyses for diagnosing specific vision-model failures. Its high-fidelity, non-differentiable approach focuses mainly on average-case robustness, while its extensibility also permits worst-case analyses.

Adversarial robustness

  • Adversarial-robustness research studies worst-case inputs, while 3DB primarily uses non-differentiable, high-fidelity rendering to analyze average-case robustness to semantic properties.Prior work includes adversarial 3D or physical-world examples [EEF+18] [BMR+18] [AEI+18] [XYL+19] [LTL+19]; 3DB can reproduce such studies by substituting a differentiable renderer, custom control, and search policy.Source: §6 · p. 12

Robustness to synthetic perturbations

  • Prior 3D-rendering studies analyze factors such as pose and geometry, and 3DB seeks to unify failure-mode discovery across these and other analyses.Related work includes systems examining object orientation, zoom, and background [ALG+19].Source: §6 · p. 12
  • Synthetic-perturbation studies examine transformations such as rotations, style transfer, corruptions, background changes, and occlusions, while 3DB provides controls and search strategies to reproduce and compose such analyses.Examples include rotation and translation, style transfer, and common corruptions [HD19] [KSH+19].Source: §6 · p. 12

Other types of robustness

  • Unlike work evaluating models on naturally collected distribution shifts, 3DB is synthetic, though the paper reports that it is realistic enough to indicate real-world performance.Examples of nearby but non-identical test distributions include ImageNet-v2 and ObjectNet.Source: §6 · p. 12

Interpretability, counterfactuals, and model debugging

  • 3DB frames fine-grained scene control as a way to find specific failure modes, complementing local and global interpretability methods.The paper notes that local explanations can be fragile or misleading about global behavior, and that concept-based explanations can lack a causal link to features models use.Source: §6 · p. 13

Robustness and simulation

  • 3DB’s distinguishing goal is diagnosing specific failures in existing models, unlike simulation platforms that may share components such as physics engines or photorealistic rendering.The framework aims to unify prior robustness studies and support new analyses.Source: §6 · pp. 12–13

7 Conclusion

The paper presents 3DB as a unified framework for diagnosing vision-model failure modes with high-fidelity rendering. Its case studies uncover model sensitivities and biases, and its simulation-based analyses predict physical-world behavior.

7 Conclusion

  • 3DB is a unified framework for diagnosing vision-model failure modes using high-fidelity rendering.The authors encourage the community to build on it to uncover further model vulnerabilities.Source: §7 · p. 13
  • The paper demonstrates 3DB through use cases that examine classifier sensitivities to realistic scene and object perturbations and discover model biases.Source: §7 · p. 13
  • The authors report that debugging analyses conducted in 3DB simulation predict model behavior in the physical world.Source: §7 · p. 13

A Implementation and scalability

3DB distributes rendering and inference across worker nodes, with an orchestrator coordinating searches and results. Its render throughput scales largely linearly with available CPU cores, subject to a limit imposed by concurrent policy instances.

A Implementation and scalability

  • An orchestrator composes controls into a search space, selects configurations through a user-specified policy, and schedules them across workers for rendering and inference.A logging module aggregates and saves results; a separate dashboard reads the logs for exploration.Source: A Implementation and scalability · p. 18
  • 3DB reaches 415 FPS average and 800 FPS peak with dummy workers, and around 100 FPS in the paper’s main experiments.The main experiments use a complex background requiring 15 seconds of rendering per image; the orchestrator’s concurrent policy instances limit scalability.Source: A Implementation and scalability · p. 18
  • 3DB’s rendering efficiency largely scales linearly with available CPU cores, while actual client use is limited by the orchestrator’s number of policy instances.The paper runs one policy instance per environment–3D model pair, with concurrent instances limited to control orchestrator memory.Source: A Implementation and scalability · p. 18

B Experiment Dashboard

The dashboard lets users explore how controls influence logged experiment samples, while an iOS app helps align physical scenes with renderings. Users can also adapt 3DB’s predefined controls or implement custom ones.

B Experiment Dashboard

  • The dashboard explores control effects in JSON logs using heat-map axes, exact-value sliders, and parameters that leave samples unfiltered.Two controls must be assigned as heat-map axes; hovering over a cell filters samples in that region.Source: B Experiment Dashboard · p. 19

C iPhone App

  • The iOS app overlays a selected rendering or its edges on a camera view to help align a physical object and environment with the rendered scene.Users can adjust overlay transparency; the app connects to the dashboard’s backend.Source: C iPhone App · pp. 19–20, Figure 19 · p. 20

D Controls

  • 3DB’s controls modify interactions among an object, background, and camera to generate varied renderings, and users can build custom controls for their use cases.Controls use Blender’s Python API, bpy; the framework also provides predefined controls.Source: D Controls · p. 20

E Additional Experiments Details

The appendix documents the models, environments, and resources used for the experiments. It reports a 19-model, 20-environment setup for one analysis and a single-mug, 408-environment setup for another.

E Additional Experiments Details

  • The experiments use a pretrained ImageNet ResNet-18 from torchvision, with code, 3D models, HDRIs, and configuration files released in the 3DB package.The appendix describes experiment-specific models and environments.Source: E Additional Experiments Details · p. 21

E.1.1 Analysing a subset of backgrdounds

  • The background analysis uses 19 3D models and 20 2K HDRI environments.Some models come from YCB [CWS+15]; others were purchased and scanned into meshes.Source: §E.1.1 · p. 21

E.1.2 Analyzing all backgrounds with the “coffee mug” model.

  • The all-background analysis uses one coffee mug model and 408 HDRIs at 2K resolution.The single model was chosen to keep computational resources under control.Source: §E.1.2 · p. 21

E.2 Texture-shape bias (section 3.2)

The appendix provides experiment settings and additional visualizations for the paper’s analyses, including texture changes, object orientation and scale, physical-world testing, and system performance.

E.4 3D models Heatmaps (Figure 12)

  • The 3D-model heatmaps use the Figure 23 models in a virtual studio environment.The appendix identifies the experiment’s model and environment settings.Source: §E.4 · p. 22

E.5 Case study: using 3DB to dive deeper (Section 3.4)

  • The case study uses only the mug model in the studio setting.An additional figure shows the correlation of mug liquid mixture with model predictions, averaged over random viewpoints.Source: §E.5 · p. 22, Figure 22 · p. 23

E.6 Physical realism (Section 4)

  • The physical-realism experiment uses iPhone 12 Pro photographs and a studio environment carefully reproduced from reference pictures, geometry, materials, and HDRI lighting.The experiment uses the models shown in Figure 15.Source: §E.6 · p. 22

E.7 Performance scaling (Appendix A)

  • The performance-scaling experiment runs 10 policies, at most five concurrently, with 1,000 renders per policy using a 2K HDRI environment.Source: §E.7 · p. 22

E.3 Orientation and scale dependence (Section 3.3)

  • Accuracy degrades for non-spherical objects as heading or tilt changes, unlike spherical objects, and also depends on camera zoom.The experiment uses the same models and environments as Appendix E.1.1.Source: §E.3 · p. 22, Figure 21 · p. 23

F Omitted Figures

  • Additional plots show accuracy distributions across object heading, tilt, and zoom, while another figure plots mug-liquid mixture correlations with predictions across random viewpoints.The texture experiment’s additional examples show predictions averaged across objects and textures.Source: Figure 21 · p. 23, Figure 22 · p. 23, Figure 23 · p. 24

E.2 Texture-shape bias (section 3.2)

  • After texture replacement, the classifier tends to predict based on texture more often than based on object identity.The experiment uses seven tilable textures, the Figure 23 models, and a virtual studio environment.Source: §E.2 · pp. 21–22, Figure 23 · p. 24

Related papers

Loading 2106.03805v1…