For programmers, the benefits the World Wide Web was supposed to bring never occurred.
by Andy Wilson
EDITOR
[email protected]
In many respects, the technology revolution promised by the World Wide Web never happened. By now, every desktop was supposed to be equipped with live video feeds, remote video conferencing, and speech over the Internet. Trade-press magazines were supposed to become obsolete, replaced by 24/7 rehashed press releases from a host of dot-com companies.
For engineers and engineering managers, the most important technology that the "Wonderful Web" promised was ease of evaluating new products and porting software to new DSPs and CPUs. Today's machine-vision systems designers certainly have the first of these. Nearly every machine-vision and image-processing company fills its Web pages with new-product information, frequently embellished by marketing publicity. Interested parties can often download data sheets of these products for further evaluation. And, by bringing all of this information together, magazines, such as Vision Systems Design, help designers by identifying new technologies, products, and applications.
For programmers, however, the benefits the Web was supposed to bring never occurred. While it is possible to download some development kits, programs, libraries, design tools, and compilers, programmers still face engineering managers demanding faster code generation.
Despite the emergence of GUI kits and drag-and-drop programming interfaces, engineering managers often use tried-and-tested techniques, programs, and products when developing systems. The promise of the Web, however, was to bring new ways and methods to product development. And, for a brief time, some companies did try.
By remotely hosting DSP boards on Internet servers, designers can transmit C code over the Internet, run this code on a processor, and discover how fast the code will run. Unfortunately, that's as far as it goes. Once you have the benchmark, you can make one or two choices. And, because every manufacturer does not participate in such technology, remotely benchmarking code for a number of processors is impossible.
Pity the developer of image-processing and machine-vision software. Often, such software is not only CPU-dependent, but run times can be dependent on company-specific hardware. For machine-vision and image-processing developers, problems are application-specific. Many designers can be seen at a machine-vision trade show carrying photographs of hinges, brackets, and gaskets of parts to be inspected, or, in some cases, even the parts themselves.
Looking for a solution
What these people are looking for is a solution. Often, however, they discover a combination of lighting, GUI-based machine-vision software, proprietary hardware, and machine-vision systems. After a trade show, many companies "qualify" their leads. In essence, attendees not building a product for Ford, Boeing, Phillip Morris, or other national companies will probably be ignored.
With all the engineering software and hardware available, many different machine-vision tasks can be accomplished rapidly. And, as vendors of hardware and software make their products more user-friendly, the task of building systems should become easier. But few vendors have yet to encompass the notion of "self classification," in which a potential customer can remotely transmit images to a host Web site, develop image-processing code remotely, and then benchmark the application.
Obviously, the main reason for this is cost. The time, effort, and materials needed to develop such remote-based systems would incur substantial costs. Once developed, however, the need for designers to acquire specific evaluation hardware and software would be reduced, the proliferation of OEM products would increase, and product time-to-market would be reduced.