Solving a user's problem in automated microscopy involves several hardware and software components, which usually come from different vendors:
- Microscope
- Motorized components and motor controllers
- Cameras
- Image digitizers
- Computers and standard peripherals
- Image processing
- Image printing
- Statistical data processing
- Other "standard" desktop applications
The list certainly can be longer in particular applications. In most cases the unifying piece is an image processing package, which provides a user with support for several cameras, digitizers, microscope automation equipment, etc. The situation resembles how before Windows (the following discussion is limited to the PC/Windows platform) each word processor had to support each video adapter. The situation for common desktop applications has been rectified by standardizing interfaces between parts provided by different vendors and the operating system. Each video display adapter, or printer, or even scanner comes with a driver, which encapsulates all the specific knowledge about the hardware. To the rest of the software that runs on a computer it does not matter which driver it talks to.
This did not happen yet in the field of automated microscopy. The enabling factor exists - it is the standard way of communicating between software components on the binary level in the operating system, known at the moment as ActiveX. This alone, however, is not enough. What is needed is a software standard for interfacing microscope automation equipment and image acquisition devices. The wide acceptance of TWAIN suggests that it is not an impossible task.
Adoption of this model would allow each vendor to concentrate on what he knows best: making stage controllers and writing drivers for them, making video digitizers or cameras and writing drivers for them, making image processing tools and not worrying about support for a new camera coming to market. The benefits are well known from the recent history of desktop computing and don't have to be repeated here.
The ultimate beneficiary will be the user. He will not be tied any more to a particular combination of equipment and software that is known to work together. The cost of complete solutions would likely drop because the vendors would save a lot of resources on duplicated support efforts. The specific user knowledge, realized as macros for an image processing package, would become more valuable because it would transcend any particular hardware configuration for which it was developed.
Role of system integrators would change. They would make choices to provide the most cost effective solution for the end user on the basis of performance and cost and not on the incidental fact of support of some hardware by some software.
The software architecture and list of commands presented here serve dual purpose. It is a practical solution for the hardware manufactured by TOFRA, and an attempt to suggest a common interface for microscope automation to the industry. All comments are welcome.
Home > ScopeTool software > Integration