 |
| 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. |
|
HOST
INTERFACE
The PCI bus is the enabling technology that gave designers of frame grabbers the means to
stream image data into system memory in real time where it could be processed by the
ever-increasing power of host CPUs. This paved the way for the adoption of the PC as a
real-time imaging platform. |
|
| 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. |
|
CATEGORY
ONE: ACQUISITION ONLY
The entry level or basic frame grabber for standard color or monochrome analog video like
PAL and component RGB or CCIR, may use an off-the-shelf video decoder chip from
manufacturers like Philips, Brooktree or Samsung for all acquisition functionality (A/D,
PLL, etc.). |
|
| 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. |
|
Figure 1. A variable scan frame grabber
is comprised of discrete components and digitizes images from standard and non-standard
cameras. |
|
| 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. |
|
CATEGORY
TWO: INTEGRATED DISPLAY
Display may be required to visualize a process to make sure the system is running and
operational. It is also required to calibrate the system, typically using a reference
image. And on-board display integrated into the frame grabber design is required for
real-time visualization without adversely affecting the performance of the image
processing or analysis. |
|
| 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. |
|
Figure 2. On-board display linked to
acquisition by local bus provides a single slot solution for acquisition and display
tasks. |
| . |
| 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). |
|
Figure 3. The graphics overlay
functionality of Matrox Corona or Genesis-LC frame grabbers can be used to annotate images
in real time without affecting the contents of the image buffer. |
|
CATEGORY 3:
ON-BOARD PROCESSING
The demands of on-line inspection may be greater than what a frame grabber which relies on
the host for processing can handle. In this case, on-board processing functionality is the
answer. Custom ASICs and DSPs provide a combination of programming flexibility and
processing power. But on-board processing alone is not enough. Sufficient I/O to keep
processors fed and data moving is required. |
|
| 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. |
|
SOFTWARE
An integral part to any frame grabber is software support. While traditional 'C' library
toolkits are the norm, ActiveX controls for vision are making a strong debut. Some higher
level Windows-based packages are available as well, if an interactive/end-user approach is
required. |
|
| 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. |