imaging and machine vision europe october/november 2011
www.imveurope.com
Image courtesy of MVTec
34
image processing libraries Programming power
Greg Blackman on the developments taking place within image processing libraries
The development of image processing algorithms like those for pattern matching over the last 30 years has been one of the major advances in machine vision. When machine vision was still in its infancy, it was very much a science, with precise control over lighting and the environment necessary for the technique to work. Developing robust algorithms has meant changes in ambient lighting aren’t such a problem and it has moved what we now think of as machine vision out of the lab and onto the factory floor. Making machine vision more robust through
the image processing tools still holds true today and, as Pierantonio Boriero, product line manager at Matrox Imaging, comments, a good imaging software package should enable the user to simplify the mechanical setup of the system. ‘It will allow the engineer to relax some of the mechanical constraints in system design,’ he says. ‘If you look at the evolution of pattern recognition technology, the earlier implementations required a lot of mechanical fixturing to present the part to the vision system in a certain orientation. But with the development of geometric pattern recognition, for example, where you’re able to find a pattern at any angle, you’re able to remove that mechanical constraint from the system.’ The same applies to illumination and new image processing tools mean the system
A fruit sorting and inspection system uses Matrox Imaging Library (MIL) to process images of apples. Binarisation and blob analysis are used to separate the fruit from its background and to obtain dimensions like Feret diameters and elongation
can deal with more complex images with less uniform lighting. While the user can develop image processing
Deformable 3D matching is used in bin picking applications, with the parts recognised irrespective of angle or orientation
tools in-house, commercial imaging libraries, such as the Matrox Imaging Library (MIL), Common Vision Blox from Stemmer Imaging, Halcon from MVTec, or Scorpion Vision from Tordivel, to name a few, provide a reasonably comprehensive set of software tools for those developing vision systems. ‘The benefit of an image processing library is that most of the programming has already been done,’ states Boriero. ‘But moreover, you’re benefitting from the fact that there are many other users of the tool and the improvements and developments catering to their needs as well. If you’re looking at a library that’s been around for a while, you’re working with a tool that you know has been successfully deployed for many years in the field.’ There are other arguments Dr Wolfgang Eckstein, managing director at MVTec Software, gives for choosing a standard product: ‘Generally, long-term maintenance of the software is not a primary consideration for in-house developments – software tools that have been developed in-house might not be able to run on 64-bit machines, for example.’ Upgrades to 64-bit processors require a
substantial rewrite of the code if the software was developed in-house. By comparison, Halcon has offered a 64-bit version of its imaging library for eight years. Time-to-market is also an important
factor for OEMs developing systems for new application areas. ‘Writing and developing the algorithms takes time – you need algorithms to begin with to allow you to work on the machine,’ comments Dr Eckstein. A standard imaging library, however, provides prototyping environments for feasibility studies, which for Halcon is HDevelop. A similar problem exists for integrators, which need to design and develop systems quickly for their customers. A further problem with in-house development
Eckstein adds is maintaining the algorithms when software engineers leave the company. Stability and reliability is important and provided for by a standard imaging library. ‘The user expects a fully equipped toolbox
from an image processing library,’ states Boriero. ‘In addition, they want the peace of mind to know that if application requirements evolve or if they have to tackle new applications that they’ll have the tools to address these changes. They might not use every appendage of the toolkit, but they need to know they’re there if they need them.’
Page 1 |
Page 2 |
Page 3 |
Page 4 |
Page 5 |
Page 6 |
Page 7 |
Page 8 |
Page 9 |
Page 10 |
Page 11 |
Page 12 |
Page 13 |
Page 14 |
Page 15 |
Page 16 |
Page 17 |
Page 18 |
Page 19 |
Page 20 |
Page 21 |
Page 22 |
Page 23 |
Page 24 |
Page 25 |
Page 26 |
Page 27 |
Page 28 |
Page 29 |
Page 30 |
Page 31 |
Page 32 |
Page 33 |
Page 34 |
Page 35 |
Page 36 |
Page 37 |
Page 38 |
Page 39 |
Page 40 |
Page 41 |
Page 42 |
Page 43 |
Page 44 |
Page 45 |
Page 46 |
Page 47 |
Page 48 |
Page 49 |
Page 50 |
Page 51 |
Page 52 |
Page 53 |
Page 54 |
Page 55 |
Page 56 |
Page 57 |
Page 58 |
Page 59 |
Page 60