Feature Article:
Why We Still Need OPI
By James E. Porter
Back in 1989, when the open prepress interface (OPI) specification was initially developed, it addressed a huge bottleneck that occurred in digital prepress workflows because image files, especially color, are very large. Then, the networks connecting page layout workstations to servers and output devices were limited, able to yield only a portion of the theoretical 10 Mbps through-put. OPI, an extension to the PostScript language permitted applications or users to insert a set of comments describing the location, size, and cropping of an image in a page layout, rather than the image itself. Using this low-resolution "proxy" or FPO file in place of the high-resolution master in page layouts significantly reduced the total file size, preserved precious bandwidth, and increased overall throughput.
But that was then and this is now. Today it is common to find well-designed networks using switches and 100Base-T/Fast Ethernet networks to connect G3 Power Macintosh workstations to UNIX and Windows NT servers. And Gigabit Ethernet is beginning to enter the realm of economic feasibility for the publishing and printing industries. So why do we still need OPI?
This article delves into some of the reasons that OPI as a methodology, including APR and DCS, is still an important tool for maintaining a productive prepress operation. It also explains how OPI can facilitate the conversion from PostScript to PDF workflows that is now beginning.
How OPI Works
Irrespective of the vendor's system or operating platforms, OPI is a relatively straightforward process. After an image is scanned or captured at high resolution, it is saved to a file server or image server. Using hot folders and polling, or events supplied by the operating system to initiate the process, the OPI application subsamples the image to create a low-resolution proxy. The low-res FPO sample is usually saved in TIFF or EPS format, depending on the high-resolution image, with the FPO version saved at 72 dpi to match the resolution of most desktop monitors.
Since the OPI sample generator can recognize multiple file formats, it can easily create low-resolution FPOs of images that may otherwise be unreadable by the page-makeup application. Some applications, for example, are unable to read the Scitex Handshake LW format or to process TIFF images compressed with certain flavors of CCITT compression.
The most commonly used file formats include TIFF, EPS, DCS v1 and v2, Scitex Handshake CT, and JPEG (these should be the minimum formats supported by any OPI server). Additional formats include Scitex Handshake LW, CopyDot TIFFs, and Photoshop Native.
To facilitate page makeup, designers accesses the FPO from the server, place it—including cropping,
scaling, and rotation—then save the final piece. When the file is output to a PostScript device, two things happen. First, the OPI producer, as the page layout application is known, writes a set of comments according to the OPI specification (see “A Little History” sidebar). The comments describe the FPO image's position and characteristics (cropping, scaling, rotation) on the page and also the name and search path that will locate the high-resolution image file on the server. Next, the OPI image server, known as an OPI consumer, performs the image swap and sends on the "fat" PostScript file to the RIP for processing and output. Depending on the system, the high-res image file can be (1) separated before being saved on the server, (2) separated by the OPI application on the server, or (3) saved in a composite format for separation by the RIP.
Workflow Enhancement
No matter how fast networks get, OPI still performs several important roles. The first is strictly a matter of optimizing capacity use: there is no reason to burden either the network or the page layout workstation with extraneous data. The performance of both declines as the file size increases - exponentially with Ethernet-based networks. (That is, if the file size increases by a factor of two, the performance declines by a factor of four.) As for the page layout workstation, using the high-resolution image data significantly slows down the import process. For example, a 30 MB image will require five seconds to "open" in QuarkXPress at full resolution using Fast Ethernet, but the proxy will open almost instantaneously. If the OPI system runs under Windows NT and there are multiple concurrent users, performance degrades further.
