TWAIN: Linking Applications and Images
A White Paper

What TWAIN Is

TWAIN defines a standard software protocol and application programming interface (API) for communication between software applications and image acquisition devices.

History: The Issues that started TWAIN

In desktop publishing's early days, most publications contained only text and simple black-and-white line drawings that were output to black-and-white laser printers. In recent years, however, computer hardware and software has become much more sophisticated. Both business professionals and graphic artists can now create and output complex, full-color publications. This near-commercial-quality work may include black-and-white, grayscale, and color images acquired from desktop and hand-held scanners, or from still video, digital cameras or image capture boards. This growth in technology means vendors are faced with a challenge: to supply customers with hardware seamlessly for an efficient, easy-to-use computing process. Unfortunately, image acquisition remained a difficult process. To acquire and place an image in your publication, you must leave the application in which you are working. Then you must locate and open a hardware driver, set the device options, acquire the image, save it to disk, close the hardware driver, return to the application, then locate and read in the image file from disk. The process was time-consuming and tedious, and not how business professionals, designers, or publishers wanted to work, particularly with the increasing need for on-demand integration of images acquired in real time./p>

History: How TWAIN Provided a Solution

When the image-acquisition issue surfaced, hardware and software developers began defining their own image acquisition interfaces. This was a step in the right direction, but it soon became apparent that high numbers of proprietary interfaces were not the ultimate solution. It's inefficient to require a software developer to write a driver for each device they need to support. Conversely, it doesn't make sense to ask a hardware vendor to write a different driver to interface with each software application. Most importantly, it isn't acceptable that users must deal with many unique application/device driver files.

Users need a painless way to get image data into their applications. Software developers need compatibility with the widest range of output devices without writing and maintaining multiple device drivers. Hardware developers need compatibility with the greatest number of applications without application-dependent coding.

The solution to this situation is an open industry interface that directly acquires image data from external sources while within an application. With this, each software developer supports a standard data acquisition manager and each hardware vendor writes one driver for their device. Hardware vendors will benefit because they need only provide one standard driver for their device, which can then be used by all software applications supporting the standard data acquisition interface. Software vendors will be freed from writing and supporting device drivers, or from soliciting support for their own proprietary interface. Software vendors will also benefit because one single interface will support those vendors writing these device drivers. Users will benefit because they can place a smaller set of drivers at the operating system level and take advantage of seamless images acquisition from a large number of applications. 

History: Forming the TWAIN Consortium

In early 1990, the formation of the Macintosh Scanner Roundtable group heightened the imaging industry's awareness of the need for an open interface. While participation in the roundtable was high, it was difficult to resolve issues and progress was slow. At one of the group's last meetings in 1990, it was suggested that a set of industry leaders form a consortium and create a specification for review, revision, and ultimate adoption by the imaging industry.

The Working Group's primary goal was promoting imaging products through developing an easy-to-use image acquisition interface and educating users about it. A key requirement of participation was that members be willing to represent a broader interest than that of their own company so that they represent a wide spectrum of application developers (desktop communications and OCR) and hardware manufacturers (hand-held, desktop, and high-end color imaging devices). The result was that working group members represent diversity in the industry, and bring in-depth imaging experience to both hardware and software development, and marketing fields.

At the TWAIN Working Group's first meetings, engineers faced the huge task of reviewing specifications and resolving outstanding requirements issues. Most Working Group companies had written their own interface for direct image acquisition, and these were considered, as well as more than two dozen specifications provided by other companies. No single specification or protocol, including those from operating system vendors, provided the completeness, richness of functionality, and ease of implementation that was required.

TWAIN Working Group engineers participated in monthly workshops to define the specification. A separate Marketing Working Group met to discuss publishing a toolkit, supporting the interface, and other issues, including how to inform the industry and public about the interface.

Besides the TWAIN Working Group, more than 175 major imaging hardware and software companies form a group called the "TWAIN Coalition." This larger group reviewed the TWAIN specification and provided feedback prior to its release. The TWAIN Working Group took comments and suggestions from the TWAIN Coalition, examined the costs and benefits of the modifications, and decided which to incorporate into the specification. The Specification is now in it's third revision.

Goals of the TWAIN Specification

TWAIN was designed to provide a consistent, easy integration of image data between sophisticated input devices and software applications. More detailed Working Group goals for the specification included:

• Multiple platform support - The interface must work across many Operating Systems. Use of platform-specific mechanisms should be kept to a minimum.
• Support for multiple devices - These include hand-held scanners, flatbed scanners, slide scanners, image capture boards or frame grabbers, digital cameras and image databases-a broad range of raster image- generating devices.
• Widespread acceptance - Provide an interface that is well-defined and enables the majority of the leading hardware and software developers to provide drivers for their devices or include support through their applications.
• Extensibility and revisions - As the industry grows, the specification's architecture should be extensible and able to handle new, unknown conditions. Revisions will be backwards-compatible with code written to earlier versions of the specification.
• Easy implementation - The interface and its documentation should be clear, well structured, well written, and intuitively designed for developers to learn and write the code for it.
• Longevity - While the aim is to provide a solution as quickly as possible, the Working Group is doing all it can to make sure the interface is structurally sound and encompasses all functionality necessary to provide a single solution for the industry that will last for several years, or until such time as a facility like this might be supported at the operating system level. It is a goal of the Working Group that this functionality be incorporated at the operating system level and be TWAIN compatible.
• Multi-data Capacity - This general data interchange mechanism must be able to transmit data in existing standard formats and native file formats such as TIFF, PICT, and DIB. Furthermore, TWAIN was designed to easily support data type extensions outside the realm of images (such as text, facsimile data and vector graphics.)

Architecture

TWAIN provides a simple methodology for universally connecting TWAIN-compliant applications with TWAIN-aware devices. The model for how applications interact with the source of input data can be described through a four-layer protocol: the Application Layer, Protocol Layer, Acquisition Layer and Device Layer. The acquisition components correspond to these layers and include the application, Source Manager, Source and physical hardware device. The application communicates through the Source Manager to a Source driver which represents the physical hardware device that generates image data.

The hardware interface element of the TWAIN architecture is the Source. A Source is a TWAIN entity whose purpose is to get data from a hardware device and provide it to a TWAIN-compliant application. A Source is typically written by the hardware vendor to control their peripheral device. These devices are usually a physical piece of hardware, such as a scanner, although a virtual device (such as an image database) also fits the Source model. The device may be locally connected or remotely accessed over a network.

The central element of this architecture is the Source Manager (SM). The SM's primary role is to establish and manage the connections between the application and the sources. The SM allows the user to select the desired source, loads and unloads the selected source, and makes sure that all calls from a particular application are correctly routed to the appropriate source. The SM is implemented as a shared library on the Macintosh and a Dynamically Linked Library (DLL) under Microsoft Windows. When the application needs to communicate with a Source, it calls the SM with a correctly addressed message. An application never calls a Source directly.

To acquire an image using the TWAIN protocol, the user first chooses "Select Source" from the Application's menu. "Select Source" identifies the source device from which the image will be acquired, and is only accessed by the user when it's necessary to switch between connected devices. "Select Source" invokes the Source Manager and a selection dialog box appears. Once the source is selected, the user chooses "Acquire" to initiate the image acquisition process. "Acquire" brings up the Source Manager to facilitate a process called capabilities negotiation. This takes place between the application sending messages (describing the data it wants) and the Source (defining the data it can provide). When negotiation is complete, control is passed to the Source. The Source's user interface allows the user to set scanning options and start the scan or the user interface can be suppressed leaving whatever has been previously negotiated as the settings.

Originally Published March 17, 1992
Last Revised: February 6, 2001