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.

FEATURE ARTICLE PAGE 2

BACK TO NEWS