Machine vision benchmark

geckokittenAI and Robotics

Oct 17, 2013 (3 years and 10 months ago)

86 views

Machine vision benchmark
Stuttgart, Nov. 9th, 2011
VIALAB Origins 
•Research program funded by Regione Emilia‐
Romagna
•From industrial to technological districts
•Projects are lead by industrial partners
•Project duration: 2 years
VIALAB
Applied Industrial Vision Laboratory 
Computer Vision as an enabling tecnology for the 
manufacturing automation industry
2
VIALAB Partners
•Datalogic
•Automation  (Prime Contractor
)
•Scanning
•System
•SPA
•Logistics
•T3LAB, Region Emilia‐Romagna High Technology Network
•DEIS, University of Bologna
•CRIT
3
VIALAB topics
•Computing platforms and 
computational models
•HW acceleration of machine vision algorithms
•3D Vision
•Benchmark of machine vision libraries
4
Goals
of VIALAB benchmark
•Provide an independent benchmark of the 
most relevantmachine vision libraries
•Construct a framework that allows an easy 
repetition of performance measures
•On new libraries
•On new versions of libraries that have 
already been tested
•Performance metrics and measures must be 
comparable
5
Stakeholders
•Users and integrators
•Suppliers
“The Middlebury Stereo Dataset and the NIST 
Face Recognition Grand Challenge have 
succeeded well in advancing their respective 
research algorithms by providing well‐defined 
challenge tasks with ground truth and evaluation 
metrics.”[2]
When possible, we want to do it in 
cooperation with library suppliers
6
What libraries?
•Primary target libraries identified in a survey of 
several machine vision users, integrators, OEM 
conducted during the project
•Primary target libraries
•Cognex VisionPro
•DALSA Sapera
•Matrox MIL
•MVTec Halcon
•Open to all vendors that are willing to participate
7
Expected from
library suppliers
•Review of methodology
•In general
•Specific challenges
•Definition of the roadmap
•Availability of their library (and calibration targets)
•Construction of datasets
Provide library specific procedures for the solution 
of challenges (solutions)
8
Comparable results
•Toolkit suppliers report tests they perform using the 
standard benchmark
•Standard procedure to report results
•See [1]
•Toolkit suppliers are invited to provide functions for 
the benchmark
•If they don’t, we implement these functions
•Running test cases in a single site guarantees that results 
will be comparable
•Results will “include the code fragment used to solve the 
benchmark task. Beside transparency, this will allow users 
to learn more about the use of a given system.”[1]
9
Benchmark platforms
•Different HW platforms
•Simple embedded platform
•PC‐based
•Single core vs. multi core
•32 vs. 64 bit
•Different SW platforms
•Linux?
•Windows
•HW acceleration
•GPU
•FPGA?
•Dedicated boards?
10
Benchmark framework
•Not an episodic assessment but a tool (a test bench) 
that supports and assesses the progress of the 
technology
•Explicit and detailed definition of each challenge
•Supporting SW is open
•Purely image/ground truth based to make it 
repeatable
11
Algorithms
•Low level operators (e.g. Sobel)
vs. Application functions
•Prototype challenge: Camera Calibration 
•Future challenges?
•Object localization in real world coordinates
•Object recognition
•Object localization in image
•1D measurements
12
Performance metrics
•Speed
•Accuracy
•Precision (repeatability)
•Resolution
•Robustness
•Parameters
•Deformations
A general definition of each + a challenge specific 
definition
13
Performance metrics
From an MVTec presentation
14
System related metrics
•Interoperability
related to complexity of adapting to OpenCV based challenge 
APIs
•Usability
related to complexity of solutions
•Footprint (code and data)
•Modularity
•Portability
•Supported target systems
•Requirements for port
15
System related metrics
•How to evaluate them?
•Usability
•Number of library operations invoked inside solutions
•Max/total number of parameters
•Atomic parameters
•Weight of a parameter based on domain of possible values
•Specific complexity function yet to be defined
•“Standard”code complexity metrics
•Interoperability
•Complexity of image marshaling
•Canonical representation = OpenCV
16
To be discussed
with
participants
Robustness
•Different degrees of deformation (See [1])
•As a starting point, MVTec proposes a number of 
benchmarks, each of which consists of a set of image 
sequences.
•Within each sequence the influence of a “defect”is 
continuously increased. 
•For example, in template matching, an original image of a 
PCB could be generated and then successively defocused 
to provide a specific image sequence. 
•The quality of specific software can then be measured by 
the number of images that can be processed correctly.
17
Robustness to what?.1
•Traslation
•Rotation
•Scaling
•Perspective deformation
•Intra‐class variance
•Clutter
•Occlusion
18
Similarity
Robustness to what?.2
•Noise
•Defocus
•Inhomogeneous illumination
•Overexposure
•Low contrast
19
Noise models
•Additive gaussian
Imaging sensors operating at low light levels
•Salt and pepper (on/off)
Faulty switching devices, dead pixels, A/D converters, 
bit errors in transmission
•Speckle noise –Multiplicative 
Less important in our case (echographic images, 
radar).
•Shot noise
Based on sensors characteristics
20
Synthetic images
•How can we handle all these deformations and their 
different degrees?
•How can we handle the combination of different 
deformations with different degrees?
Synthetic images 
We have created a tool for the introduction of 
calibrated deformations in a base image
Models for artificial deformations to be discussed 
with participants
21
Synthetic images
•Synthetic images are an accepted practice in the 
scientific community (e.g. [3])
•“…to use synthetic images, where ground truth is 
known by design. 
Paradoxically, such synthetic image sets may in 
many ways be more natural than an arbitrary 
collection of ostensibly “natural”photographs, 
because, for a fixed number of images, they better 
span the range of possible image transformations 
observed in the real world.”
22
Parameters
•Generally applicable
•Camera resolution
•Optics
•Computational platform
•Challenge specific, e.g. for the calibration challenge
•Quality of the physical target
•Number of calibration images (or equivalent)
23
Definition of a challenge
•General definition
the functionality that is evaluated and the metrics that are applied
•Main Parameters
the parameters and deformations that are considered and the values they can have
•Component tasks
the procedure that is followed to perform the assessment
•Dataset and ground truth
rationale for the structure of the dataset and way the ground truth is created
•Evaluation metrics
how the results computed by a library are compared against the ground truth and 
how the comparison data are summarized
•Task interface
the API of the challenge, an example solution based on OpenCV, the benchmark 
framework that invokes the API, a development dataset
24
Protocol
1.VIALAB distributes the challenge definition
2.VIALAB waits for comments(how long?)
3.VIALAB distributes a revised definition of the 
challenge
4.VIALAB waits for solution (how long?)
5.VIALAB runs solutions on the test‐bench
6.VIALAB discusses individual results with 
participating vendor
7.All results are published
25
Summary 
performance indices
•Not necessarily a single performance index but, 
possibly, different indices for different facets
•All raw performance data will remain available 
•Different summarization strategies
•Review of anomalous cases
Indices to be discussed with participants
26
References
1.Wolfgang Eckstein, Comparing Apples with Oranges ‐The 
Need of a Machine Vision Software Benchmark, INSPECT 
12/2009
2.Eastman, R., et Al., Performance Evaluation and Metrics for 
Perception in Intelligent Manufacturing, in Performance 
Evaluation and Benchmarking of Intelligent Systems, Springer, 
2009.
3.http://pinto.scripts.mit.edu/uploads/Research/soainv.pdf
http://www.ploscompbiol.org/article/info:doi/10.1371/journ
al.pcbi.0040027
http://tev.fbk.eu/DATABASES/objects.html
http://www.cs.nyu.edu/~ylclab/data/norb‐v1.0/
27