Today's machine vision application demands such as different camera interface requirements and competition for system resources, have resulted in new generation frame grabbers to meet the challenges of building high-performance PC-based vision systems.

Present day frame grabbers can loosely be classified into three categories. The first category consists of boards charged with the basic task of acquiring and streaming image data to system memory in real time. Frame grabbers in the second category come with an integrated on-board display. In the last category, on-board processing is available along with acquisition and integrated display functionality. But before discussing frame grabber features and functionality, we need to talk a little about PCI.

In the beginning, PCI was positioned as a bus that delivered 132 MB/second performance, but with the PCI chip sets found on early PCs, the actual sustained performance was more like 20-30 MB/second. By sustained, we are referring to the average performance over time (as opposed to peak performance). This benchmark is a key factor for reliable image capture to host from a PCI frame grabber. With today's PCs, this is not a problem and properly designed frame grabbers can deliver video image data to host memory at surprisingly close to the theoretical maximum throughput.

Another performance handicap was that some early PCI frame grabber designs were not PCI bus masters. A PCI bus master interface is necessary for a frame grabber to transfer data to system memory for processing, without the continuous and direct involvement of the CPU. If the host CPU is busy reading pixel data, it is not processing. But as time went on, designers of PCI interface chips figured out how to make full use of PCI by implementing functionality like PCI bus mastering to optimize throughput and system performance.

Some video decoders are more suitable for machine vision applications than others. For example, a frame grabber for machine vision applications that uses a video decoder should not have automatic gain control (AGC) circuitry, as this may alter the image captured and make it more difficult for an image processing algorithm to do its job. If a decoder does have AGC, then you should be able to disable it.

The next level up for frame grabber design in the first category would be a variable scan digitizer that can be programmed to handle the non-standard video timings of devices like progressive scan cameras. These cameras are becoming the defacto standard for use in machine vision applications because they are better at freezing action while maintaining full resolution. Variable scan frame grabbers can be subdivided into two classes; analog and digital.

Looking at variable scan frame grabbers for analog acquisition and the block diagram in Figure 1, you will notice that the digitization components are comprised of discrete custom components such as one or more multiplexing units connected to one or more A/D converters. The logic to drive or receive camera timings and other signals is implemented in other discrete custom components like an FPGA, with an analog or digital PLL for video synchronization completing the design. On-board LUTs may be available to remap incoming pixel data.

Since these frame grabbers are made in part with custom designed discreet components, quality and performance can vary from one frame grabber manufacturer to the next. Measures of quality and performance are the effective dynamic range (SNR or ENOB), the maximum sampling rate or frequency of the frame grabber, and pixel jitter.

A/D converters found on today's typical frame grabbers offer 8-bit precision, effectively yielding images with 256 gray levels. Although greater than 8-bit digitization is available on some frame grabbers, it is used primarily for medical applications. In machine vision, if more dynamic range is required, digital cameras are the way to go. We will talk about frame grabbers for interfacing to digital cameras later.

The issue of pixel jitter is related to the quality of the sampling clock that is generated by the PLL or like device from the video reference signal. To obtain the lowest pixel jitter and most accurate digitization of images, you can use a camera that can send a pixel clock to a frame grabber that can receive said clock, and this will usually give the best results.

Non-standard cameras are being offered at attractive price points and it is not uncommon for an OEM or system integrator to use, for example, a double-speed camera that outputs video images at 50 frames per second (fps) instead of the typical CCIR camera that outputs images at 25 fps.

Higher camera frame rates are achieved using either faster sampling rates or by using multiple camera output readout channels. If you are working with a camera that outputs video images at 50 fps, you'll need a frame grabber that can digitize data at roughly 30 MHz. If the camera outputs data on two channels, you'll need a frame grabber that can handle multiple channel digitization simultaneously.

At Matrox, a single low-cost board was recently introduced to address capture from the cameras noted above. Using a single Matrox Meteor-II/Multi-Channel frame grabber, up to 3 channels of data can be digitized simultaneously using one board, as opposed to using multiple frame grabber boards.

Another feature of a variable scan frame grabber is its ability to handle what's referred to as an asynchronous reset operation. A camera's exposure and readout cycle is interrupted and restarted based on some external event, such as a part sensor that tells the frame grabber when the part or object of interest is in the camera's field of view, and that it should be digitized at precisely that moment.

As mentioned previously, some applications require more quality or dynamic range than what can be achieved using analog cameras. For these, digital cameras can be used. They digitize video at the source (the camera), and the frame grabber is used to transfer this data to the host computer. These cameras can read out pixel data on one or more outputs, or taps.

Several digital-signaling standards exist. You have TTL and RS-422. Up until recently, as far as digital cameras are concerned, RS-422 has been the only standard to speak of. Because of its differential nature, RS-422 is more reliable in harsh environments than TTL and this over longer distances.

A new digital-signaling standard, however, has been adopted by camera and frame grabber manufacturers. It is called LVDS (Low Voltage Differential Signaling) or EIA-644, and is fast becoming the standard of choice. Benefits to using this standard include a higher data rate and transmissions over greater distances than RS-422.

Another important feature that we are starting to see on frame grabbers is RS-232 ports. They are used to configure camera modes of operation remotely, instead of manually using DIP switches on cameras that may be difficult or impossible to access.

As well, frame grabbers with the ability to provide power to cameras are available. This simplifies cabling and eliminates the need for a separate camera power supply, reducing overall system costs.

An issue common to both analog and digital variable scan frame grabbers is pixel formatting. When acquiring multiple channels of either analog or digital video data, you'll want to be able to reconstruct the images. Some cameras output pixel data in a non-consecutive order and expect either custom logic on the frame grabber or the host CPU to reorder these pixels properly before they can be processed. At Matrox, this functionality is implemented on current boards using a custom-designed video interface ASIC (VIA).

All frame grabbers will have some amount of on-board RAM, whether it be enough to store a few pixels, one line of pixel data, an entire frame or several frames. The role of on-board RAM is to buffer image data when the system is busy servicing other PCI traffic. All new Matrox boards incorporate at least 2 MB of on-board RAM to buffer image data that is transferred to host RAM. This amount of on-board RAM ensures reliable transfers, even under high bus latency conditions, which typically occur in systems with concurrent image capture, display, graphics, network access and/or general external I/O.

The frame grabbers mentioned above require a separate display adapter in the system for visualization. While using a separate frame grabber and display card may be an acceptable solution for many applications, it can effectively double the work load on the host system for some, when the host will need to support 2 data streams; one to host memory and one to display memory for live display. And if the host is burdened with taking care of the other system functions mentioned previously, even less bandwidth and processor time is available.

A frame grabber with integrated display like the Matrox Corona or Genesis-LC can off-load the system from live image display tasks while freeing up a PCI slot. On these boards, a local bus is used to route pixel data from acquisition to display, effectively offloading the PCI bus from display traffic. Also by incorporating a design with dual data paths, image data can be transferred to host memory and display memory for simultaneous processing and visualization of image data (see figure 2).

While host CPU clock rates continue to rise, I/O between memory and CPU still lags behind, especially in a multiple CPU configuration. This is something that Matrox recognized and addressed with the Matrox Genesis scalable vision processor. Each processing node on a Matrox Genesis board has its own private memory bank that can be accessed at full speed. And processing nodes can be configured to operate in several processing topologies; parallel, pipeline or a combination of both, whichever is best suited for the application at hand.

The primary concern for a software toolkit is that it should be easy to use. It should support more than frame grabber control. For example, if you will be working under Windows, you will want a library that supports tracking of the video window. That is to say that when you move the window that holds the image being displayed, the live image will follow. Such a task takes a great amount of programming effort, and time is better spent solving applications rather than writing this code.

If time is of the essence, you may want to consider using an off-the-shelf library, like the Matrox Imaging library (MIL) that contains an extensive set of image processing functions, so that you don't have to write or maintain one yourself.

A common API across a vendor's hardware ensures maximum reusability of code. The API should also provide input flexibility by letting you choose the right frame grabber for the job with little or no code changes to the acquisition control section of your application when moving to another board.

If you do not want to code an application, you will need to investigate what interactive software is available. Matrox, for example, has a Windows-based package for off-line applications, called Matrox Inspector.

For more information, contact our Media Relations Team.