Today commercial machine vision software is classified along two lines: the conventional vision library and the vision-specific integrated development environment (IDE). Determining which software is right for a vision project depends upon a variety of factors: ease-of-use, productivity, flexibility, performance, completeness, and maintenance. This article demystifies the relative merits and drawbacks of each by contrasting the two approaches for the factors listed above. The discussion assumes that the vision tools available in both types of software are similar, if not identical, and does not explore possible discrepancies with these tools. Also, the discussion ignores the hardware platform vision applications run on as not to bias one over the other.

 

Developing an application using a vision library requires having knowledge of—some will even argue having expert knowledge of—and experience working with a traditional programming language like C/C++, C# or Visual Basic. It is also important to be very familiar with the associated development tools: code editor, compiler, linker and debugger. As many in the field attest, however, acquiring and maintaining these skill sets can be elusive and costly. In contrast, working with a vision-specific IDE requires a rudimentary knowledge of programming principles: flow control, variables and conditional/logical expressions. The required minimum skill set makes the vision-specific IDE accessible to a much broader technical audience.

 

How quickly an individual becomes productive working with a vision library is highly dependent upon his or her knowledge of traditional programming and experience, as well as the quality and intuitiveness of the vision library’s application programming interface (API) and its documentation. Making proper use of a vision library requires careful study of the supplied programming examples and documentation. And it is extremely beneficial for users to take advantage of the various training options offered by the software vendor before starting application development. A developer must also invest the time needed to properly design the initial application program architecture, as this is essential for its effective reuse in subsequent projects. Working with a vision library generally results in an overall development time measured in weeks or months. 

 

A vision-specific IDE is, unlike a vision library, designed to quickly tie together and configure the handful of operations needed for a typical vision application: get the next image, locate an object(s) or feature(s) of interest, analyze/measure/read/decode, make a pass/fail decision, and communicate results. The simplicity of this approach makes starting a new project—even from scratch—straightforward. The automation of usual application requisites (i.e., fixing an analysis region based on the result of a location operation) simplifies and thus accelerates project development. And, the modification of the application at a deployment site is less burdensome because of the all-inclusive nature of the software development environment. Working with a vision-specific IDE requires, on average, a development time frame measured in days or weeks.

 

A vision library provides users with the utmost flexibility to handle applications that require considerable and complex decision making, substantial use of custom vision or other algorithms (i.e., math and machine learning) alongside the ready-made vision tools and the need to consolidate and work on multiple views from multiple cameras. To reiterate, as discussed in the previous section, a vision-specific IDE is best suited to applications that respect the intended usage model. Deviating from the intended usage model can be awkward and messy. Furthermore, the addition of custom vision or other routines basically requires traditional programming.

 

A vision library invariably offers the best performance because it operates at a level closest to the hardware. In fact, a vision-specific IDE itself makes use of a vision library of some form or another. Working with a library also provides more opportunities for performance tuning, including manual task parallelization and offloading, and permits the most effective use of memory and the reuse of computing resources. A vision-specific IDE has an inherent performance overhead but the magnitude of this depends upon the quality of the implementation. And, typically, memory usage is not the most optimal because of the IDE’s need to maintain flexibility.

 

When a developer decides to use a vision library, the implementation of other application functions (i.e., operator interface and communication with automation and enterprise equipment) requires additional programming that is either custom or based on third-party libraries. With a vision-specific IDE, the setup of the usual ancillary functionality (i.e., operator interface and external communication) is a key characteristic of the IDE. However, advanced vision features are purposely hidden away or not exposed to ensure simplicity and thus ease-of-use.

 

Once an application developed using a vision library is deployed, any subsequent effort needed to revise or adapt it can be substantial depending on its complexity and quality of its implementation and documentation. What’s more, transferring this responsibility to another programmer can be a lengthy and difficult process. This is unlike a project developed using a vision-specific IDE, which is easier to transfer or share.

 

Choosing between a vision library or a vision-specific IDE depends on circumstances and application objectives. Developers who are willing and able to invest in obtaining and retaining traditional programming know-how, and who need their machine vision systems to deliver unprecedented levels of performance and functionality, will not go wrong using a vision library.

 

A typical vision library user is an original equipment manufacturer (OEM) that embeds machine vision into an overall machine to be sold in significant quantities over many years. If instead, users need to move from one machine vision project to another quickly and often, while delivering existing levels of performance and capability, then a vision-specific IDE is best-suited to their needs. Users of vision-specific IDEs are often system integrators with multidisciplinary technical staff bidding on one-off installations or projects that have a modest number of duplicate installations. Some commercial machine vision software vendors understand these diverging needs and offer products that cater to both user types.

 

Tech Tips

Choosing between a vision library or a vision-specific IDE depends on circumstances and application objectives.  A typical vision library user is an OEM that embeds machine vision into an overall machine to be sold in significant quantities over many years.  Users of vision-specific IDEs are often system integrators with multidisciplinary technical staff bidding on one-off installations or projects that have a modest number of duplicate installations.