Common application programming interfaces will speed time to market.
Conard Holton
For the most part, the machine-vision industry has comprised a relatively small number of companies with turnovers in the $20 million/year range. Consisting of sensor, camera, lighting, frame grabber, and software vendors, these companies have been successful because they offer very specialized products and the technical expertise to support them. In many cases, end-users in industries such as pharmaceuticals, electronics, or lumber have been faced with building a high-speed product inspection system but have no expertise in machine vision and so must contact these vendors or their system integrators to retrofit vision into an automated assembly line, an often challenging task.
For machine vision to become more widely accepted in the industrial-automation world, this scenario will have to change. With the time to market of today’s systems being a fraction of what it was 10 year’s ago, system integrators need to rapidly evaluate and compare cameras, frame grabbers, image processors, and machine-vision software. Unfortunately there are no standard means to evaluate or program these devices.
In the world of computer graphics, Open GL and DirectX give developers a set of standard application programming interfaces (APIs) that provide access to the features of 3-D graphics-acceleration chips. Because most graphics programmers and graphics-processor board vendors adhere to these standards, it is relatively easy to compare the performance of one board to another. Things are not the same in the world of machine vision, where the lack of a common API has resulted in many greatly differing solutions.
Rather than wait for machine-vision suppliers, Sun Microsystems (Palo Alto, CA) and the DARPA sponsored Vector Signal Image Processing Library (www.vsipl.org) independently offer extensible imaging and video APIs designed to fit between higher-level programming interfaces and system hardware. Supporting optional accelerators and frame buffers, developers can use these APIs to add image processing functions and proprietary image-processing algorithms by replacing defined operations through the device layer.
Yet for system integrators, no machine-vision system vendor currently supports these APIs. In fact, instead of endorsing a standard, many of those in machine vision seem bent on developing simpler APIs that support different types of cameras. For example, the Automated Imaging Association (AIA; Ann Arbor, MI) has been working for the past two years on finalizing the GigE standard for cameras.
The GigE standard would result in cameras that are Internet Protocol devices, make good use of existing IP standards, and serve the machine-vision market well. Many machine-vision companies have announced or plan to announce GigE-based products. Pleora Technologies (Ottawa, Canada), a pioneer in developing GigE, has launched an OEM board for in-camera GigE connectivity, and has agreements with camera makers such as Atmel (St. Egreve, France), Basler Vision Components (Ahrensburg, Germany), Dalsa (Waterloo, Canada), and JAI Pulnix (San Jose, CA) to develop machine-vision products.
The European counterpart of the AIA, the European Machine Vision Association (EMVA; Frankfurt, Germany), is developing a new standard called GenICam (www.genicam.org), the goal of which is “to provide a generic programming interface for all kinds of cameras.” Whether GigE, Camera Link, or FireWire is used, the API would be always the same.
Currently, the GenICam standard consists of multiple modules including a GenApi to configure the camera, recommended names and types for common features, a Transport Layer for grabbing images, and a DataStream to interpret additional data that might be appended to the image. The first version of the standard contains the GenApi module only, but others will follow.
From a technical perspective, the question is: how will these standards incorporate any type of high-level programming API? While it is important to develop standard programming interfaces that specify how to configure cameras and transport image data, the advent of smart cameras that incorporate frame-grabber and image-processing capabilities is posing a more important problem. Rather than concentrate on simple camera APIs, it will be far more important in the future to adhere to APIs that provide developers with unified programming models.
CONARD HOLTON is editor in chief of Vision Systems Design; e-mail: [email protected].