 |
Description  |
|
|
BACKGROUND OF THE INVENTION
The present invention relates to the communication of graphic image files
to an imaging device such as a color copier, laser printer, image recorder
or the like, and more particularly to an interface for processing and
forwarding rasterized image data to the imaging device in an efficient and
orderly manner.
In computer generated image recording, a plurality of computer generated
images are rasterized for input to a color copier, laser printer or the
like or for exposing corresponding frames of photographic film or another
imaging substrate. The copier, printer or film recorder (referred to
herein as an "imaging device" or "output device") processes the rasterized
image data to provide, e.g., paper copies, transparencies, color slides or
motion picture footage containing images represented by the image data.
To obtain the computer generated images, a user first generates a graphic
image file using a computer graphics program. The graphic image file may
include one or more images or frames of image data which, for example, are
in a bit mapped or text (e.g., ASCII) format. The image data are processed
by a raster image processor (RIP) which provides frames of raster image
data for use by an output device in generating images. The output device
may comprise, for example, a color copier, a laser printer, or a
photographic film recorder. Film recorders, such as those sold under the
Solitaire.RTM. and Sapphire.RTM. trademarks by Management Graphics, Inc.
of Minneapolis, Minn., USA are well known in the art. Color copiers, such
as those manufactured by Xerox Corporation and laser printers, such as
those manufactured by Hewlett-Packard Corporation are also well known.
In the past, during use of such an image generation and recording system,
the RIP would send one page or frame of image data at a time to an output
device that would then generate the image. This resulted in inefficient
use of the output device, as the processing time associated with
generating an image by the output device remained relatively constant
while the time required to produce a page or frame of raster image data
varied with the complexity of the image. It would not be unusual for the
output device to spend considerable time in an idle mode when complex
images were being processed by the RIP. At other times, the RIP would be
idle because the output device was already busy. There was no way to
minimize the idle periods and keep both the RIP and output devices as busy
as possible.
In systems where many computers communicate over a network, a plurality of
different users may compete for the use of a graphic output device.
Because of the extensive processing time often required to generate raster
image data, inefficient use of the output devices available via the
network sometimes results in an unacceptable response time for one or more
of the various users. Further, to process different graphic image files
for different output devices and end user requirements, a plurality of
different RIP modules may be needed for generating raster image data.
Examples of different available RIP modules include those known as
"PostScript," "Targa," and "TIFF."
A system for managing the processing of graphic image data by different
RIPs and different output devices is disclosed in commonly assigned,
copending U.S. patent application Ser. No. 08/246,795 filed on May 20,
1994, entitled "Apparatus for Managing Rasterization of Graphic Image
Files" and incorporated herein by reference. The system disclosed therein
minimizes the amount of time that the RIPs and output devices are idle,
and keeps these devices as busy as possible. The system also enables
different graphic image files to be processed by the same or different
RIPs and routed to the same or different output devices in an orderly and
efficient manner. Multiple instances of the same RIP, implemented by a RIP
software module, can be run in parallel to concurrently process different
graphic image files for the same or different output devices.
A problem not specifically addressed by the prior system is that some
output devices cannot immediately start generating output when the graphic
image server is ready to send the rasterized image data. For example,
imaging devices such as color copiers and laser printers have a startup
delay (i.e., a delayed "first copy out" time) even when warmed up. This
delay is necessary to allow mechanical parts to be brought up to speed and
to enable certain preliminary processes to occur, such as adjusting
lenses, cleaning a photoreceptive drum, or agitating developer and toner
to develop a sufficient triboelectric charge. In addition, devices such as
color copiers may only be able to start a first copy at a specific point
in a mechanical cycle, and it is necessary to wait for the parts to reach
the proper point before commencing imaging of the first page of a copying
run. If the imaging device finishes one page before the next is ready for
printing, the device will revert to an idle state, and the delayed first
copy out sequence will have to be repeated for the next image. Such delays
will occur if the imaging device has to wait to receive the next image
from the graphic image server, which may often be the case. The processing
of a single page at a time by a photocopier or other imaging device can
significantly reduce the production rate of multiple image files, e.g., on
the order of a 50% reduction from the maximum possible throughput. In
order to manage the flow of rasterized image data to an imaging device, an
output queue or buffer may be used to hold a plurality of rasterized image
files. These files can be output to the imaging device on an as needed
basis, to keep the imaging device running (as opposed to idling) as much
as possible. However, a substantial amount of storage space (e.g., hard
disk and/or random access memory) is required to store a plurality of
rasterized image files for subsequent output to an imaging device. A full
8.5".times.11" cyan-yellow-magenta-black (CYMK) color image page consumes
about sixty-four megabytes (MB) of memory as a bitmap. Currently, such
memory is relatively expensive and it is desirable to minimize its use.
A further problem with known image processing systems is that mechanical
misregistration in the output device can cause gaps to occur at the
transitions between different colors in the image. Color copiers, for
example, generally require four (CMYK) different color passes to form a
complete image. Photographic processors generally require three
(red-green-blue) passes. If the colors are not laid down in perfect
registration, unsightly gaps may occur at the edges of the image objects.
In the past, efforts have been directed at resolving this problem by
providing fixes in the output device itself, and the quality of the final
image was restricted to the limitations of the output device with no way
to improve thereon.
It would be advantageous to provide an interface between an image
generation system and an image output device that overcomes the problems
noted above. Specifically, such an interface should enable rasterized
image data to be forwarded to the output device in such a manner that the
idle time of the output device is kept to a minimum. Further, the memory
requirements for buffering the data before it is sent to the output device
should be minimized. In addition, processing of the raster image data
prior to forwarding it to the output device should be provided in order to
enhance the quality of the final printed image.
The present invention provides an interface for use between a graphic image
server and an imaging device having the aforementioned and other
advantages.
SUMMARY OF THE INVENTION
In accordance with the present invention, an interface is provided for
forwarding rasterized data to an imaging device. An input receives the
rasterized image data from a raster image processor. Means are provided
for compressing the received rasterized image data. An output queue holds
the compressed rasterized image data until the imaging device is ready to
receive and process an image represented by the data. A data output path
is coupled between the output queue and the imaging device for
communicating the rasterized image data to the imaging device. Means are
provided within the data output path for decompressing the compressed
rasterized image data as it is being communicated to the imaging device.
Preferably, the compression means use a lossless compression scheme such
as run length coding to compress the rasterized image data.
In an illustrated embodiment, the rasterized image data received from the
raster image processor is representative of a plurality of different
images to be provided on separate substrates by the imaging device. The
interface further comprises means for issuing control signals to the
imaging device. The control signals can comprise, for example, a multiple
copy command instructing the imaging device (e.g., a color copier) to
continue preparing additional substrates (e.g., paper or transparencies)
for imaging after a first substrate has been prepared for imaging. An
abort command instructs the imaging device to stop preparing additional
substrates for imaging. In this manner, successive substrates prepared for
imaging by the imaging device in response to the multiple copy command are
imaged with successive images represented by the rasterized image data at
the maximum possible throughput rate.
The means for issuing control signals can be responsive to the output queue
for issuing the abort command when the level of compressed rasterized
image data in the output queue has been depleted to a predetermined point.
The predetermined point can occur, for example, when the output queue is
empty. In an alternative illustrated embodiment, the predetermined point
occurs when the output queue has been depleted to the member of images for
which the imaging device will continue to prepare additional substrates
after receiving the abort command and before coming to rest. The means for
issuing control signals can also be responsive to the imaging device for
delaying the issuance of the abort command until the imaging device has
commenced preparation of a final substrate necessary for an imaging job.
For example, where the imaging device is a color copier, the interface can
wait for a signal from the copier indicating that it has commenced the
feeding of the next sheet of paper, before the abort command is issued.
The abort command will then prevent the copier from feeding any additional
sheets of paper.
The interface of the invention can further comprise an image processor
coupled to receive the rasterized image data prior to communication of the
rasterized data to the imaging device. The image processor selectively
enlarges objects contained in images represented by the rasterized image
data to compensate for potential multi-pass misregistration errors in the
imaging device. The image processor can be coupled to the input of the
interface, for processing the rasterized image data prior to compression.
Alternatively, the image processor can be coupled in the data output path
after the decompressing means, for processing the rasterized image data on
its way to the imaging device. In an illustrated embodiment, the image
processor uses a convolutional filter to enlarge objects within the image.
It is also possible that the imaging device will be capable of scanning
documents to digitize them for input to another device. In this case, the
digital image data from the imaging device can be received by the
interface of the present invention for storage in an input queue. Means
can be provided in the interface for compressing the image data received
back from the imaging device for storage in the input queue in a
compressed form.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 is a diagrammatic illustration of a network including a host
computer, a plurality of workstations, a graphic image server, and an
output device coupled via an interface in accordance with the present
invention;
FIG. 2 is a block diagram of a workstation embodying a graphic image server
and interface in accordance with the present invention;
FIG. 3 is a block diagram illustrating the interface 38 of FIG. 2 in
greater detail;
FIG. 4 is a diagrammatic illustration of a rasterized image scan line
showing how the pixel information can be run length coded (RLC) in
accordance with the present invention;
FIG. 5 is a time line illustrating the issuance of a multiple copy command
and abort command in accordance with the present invention;
FIG. 6 is a diagram illustrating a two color image for output from an
imaging device;
FIG. 7 is a diagram illustrating the two different objects which form the
image of FIG. 6;
FIG. 8 is a diagram illustrating an image resulting from a misregistration
in the imaging device; and
FIG. 9 is a diagram illustrating how the misregistered image of FIG. 8 can
be corrected by enlarging one of the image objects in accordance with the
present invention.
DETAILED DESCRIPTION OF THE INVENTION
FIG. 1 illustrates a computer network including a host computer 10 and a
plurality of personal computers (e.g., PC or Macintosh) and/or
workstations 12, each of which may communicate with the host computer 10
and with a graphic image server 14 via network path 18. One or more output
devices 16, such as a color copier, laser printer or photographic image
recorder are coupled via an interface 38 to graphic image server 14 for
the generation of paper copies, transparencies, slides or the like. Other
types of output devices that can be coupled to the network include display
monitors and non-photographic (e.g., thermal dye transfer) image
recorders.
A user creates a graphic image file that includes one or more graphic
images, using a personal computer or workstation 12 that runs commercially
available graphics software. The graphic image file in, e.g., text or
bitmap format, may then be communicated to (or already stored on) the
graphic image server 14 via network path 18. It will be appreciated that
the graphic image files may, rather than being transferred along network
18, be temporarily stored on a medium such as a diskette and then input to
the graphic image server 14 via a floppy disk drive or the like. After
receiving the graphic image file, the graphic image server processes the
data for each of the individual images contained in the file into raster
image data for transfer to the output device 16 via interface 38. The
output device then scans the raster image data directly onto photographic
film or the like to produce color or black and white slides or onto a
photoreceptive drum for transfer to an output substrate such as paper or
transparency film.
The graphic image files created by different users may be in any of several
conventional formats. Examples of such formats are PostScript files, TIFF
files and Targa files. PostScript, for example, is a device-independent
page description language optimized to render document images on display
devices, laser printers, film recorders, fax machines and
phototypesetters. In PostScript, a page is represented as a bit map, with
one bit per pixel. When an actual page is printed, each pixel
corresponding to a "1" bit is printed in black (or a predefined color) and
each pixel corresponding to a "0" bit is left blank. PostScript is
typically used for line art, with or without photographic images. TIFF
files comprise a tagged image file format bitmap and are well suited to
photographic images. Targa files are also bit mapped files particularly
well suited to photographic imaging.
FIG. 2 depicts the hardware components of one embodiment of a graphic image
server 14 in accordance with the present invention. The image server can
be implemented in a graphics workstation, such as one commercially
available from Silicon Graphics Incorporated. Well known user interfaces
are provided and include a keyboard 20 and a mouse 22. A graphic display
monitor 24 is also provided to interface with a user and can be configured
as a separate output device for viewing rasterized images generated by the
graphic image server.
Graphics capability is provided in the workstation by a graphics processor
26. One or more central processing unit(s) (CPU) 28 provides intelligence
for the workstation. Software, including raster image processing software
(e.g., PostScript, TIFF and Targa) and "job controller software" in
accordance with the present invention is stored, e.g., on a hard disk 30
or can be transferred from host computer 10. Random access memory (RAM) 32
is provided for use by the workstation and is also used for various
queues, including an output queue in accordance with the invention. A
network interface 34, such as a conventional Ethernet interface, allows
the workstation to communicate with other components coupled to network
path 18. Output port 36, which can be, for example, a standard Centronics
parallel port, couples the workstation to output device 16 (e.g., a color
copier, laser printer, image recorder, or the like) via an interface 38
that may include, for example, a universal asynchronous receiver
transmitter (UART) port or an external small computer standard interface
(SCSI).
FIG. 3 is a more detailed block diagram of interface 38, and illustrates
the data flow between the interface and various other components of
graphic image server 14. Interface 38 includes a compression subsystem 40,
an input/output (I/O) control function 42, a decompression subsystem 44
and an image processor 46. A primary data bus 50 couples the compression
and decompression subsystems as well as the I/O control to the components
of graphic image server 14 via output port 36. In particular, the various
components of interface 38 that are coupled to the bidirectional primary
data bus 50 can communicate with graphics processor 26, CPU 28, RAM 32 and
hard disk 30 of graphic image server 14 on an as needed basis.
Bidirectional output data bus 52 enables the rasterized image data from
interface 38 to be communicated to output device 16. Output data bus 52
also enables the output device 16 to communicate with the interface and
ultimately with the graphic image server 14 via I/O control 42.
In order to conserve memory resources in accordance with the present
invention, rasterized image data is compressed prior to storage in RAM 32
or on hard disk 30. This compression can be provided by compression
processor 40 on the interface board or, alternatively, the graphics
processor 26 can compress the image data as part of the rasterization
process.
The data is not decompressed until it is ready to be output to output
device 16. In order to accomplish this, interface 38 includes compression
and decompression subsystems 40, 44. In the illustrated embodiment, after
the graphics processor 26 has rasterized image data, the rasterized data
is transferred to the interface 38 where it is compressed by compression
subsystem 40. The compression can be accomplished using any known,
preferably lossless compression scheme. An example of such a scheme is run
length coding. In run length coding, each scan line of the rasterized data
is coded based on the number of consecutive pixels having the same color.
As noted above, the compression can alternatively be performed by the RIP
which runs in graphics processor 26. In this case, there is no need to
provide compression processor 40 in the interface. The same run code (or
other compression) technology would be embedded in the RIP.
Each scan line is composed of a sequence of pixels defining the color(s)
represented by that line. Thus, for example, scan line 60 illustrated in
FIG. 4 is four hundred pixels wide, and includes one hundred consecutive
pixels 62 of "color 0," two-hundred sixty-five consecutive pixels 64 of
"color 57," thirty-two consecutive pixels 66 of "color 128," and three
consecutive pixels 68 of "color 0." Instead of storing all four hundred
pixels for scan line 60, the line can be run length coded so that
substantially less data is necessary to represent the entire line. In the
example illustrated, the run length coding maintains a record of how many
consecutive pixels are provided for each color represented in the line.
Thus, the run length code for the scan length illustrated in FIG. 4 can
comprise (L=100, C=0), (L=255, C=57), (L=10, C=57), (L=32, C=128), (L=0,
C=0). In this representation, L is the number of consecutively colored
pixels and C is the color for that "run" of pixels. Each of L and C can be
represented by an eight bit word. Since eight bits only define 256
possible values, it should be noted that the two-hundred sixty-five pixel
run (reference no. 64) of color 57 is represented in the run length code
as a first run of length two-hundred fifty-five and a second run of length
ten. It should also be noted that the final run of consecutive same color
pixels in each scan line is represented by the code L=0, which means that
the scan line is filled to its end with the color represented by the final
run length code for the line. It will be appreciated that other byte sizes
and coding criteria could easily be substituted for the examples discussed
above.
After the rasterized image data for an image has been compressed by
compression subsystem 40, it is sent back via output port 36 to RAM 32 or
hard disk 30 until it is needed for output to the output device 16. The
addressing of RAM 32 or hard disk 30 in order to store the compressed data
is carried out under the control of CPU 28 in a conventional manner. In a
preferred embodiment, the compressed data is stored in RAM 32 which is
configured as an output queue. When an image is ready to be processed by
output device 16, the corresponding compressed, rasterized image data are
retrieved from RAM 32, decompressed by the decompression subsystem 44 of
interface 38 and forwarded to the output device either directly or via
optional image processor 46. The decompression subsystem 44 applies the
inverse run length code (or the inverse of any other compression) that was
applied by compression subsystem 40. In accordance with the present
invention, the decompression is done "on the fly" as the rasterized image
data is on its way to output device 16.
By providing compression and decompression in the interface, the output
queue (e.g., RAM 32) is bracketed by compression. The rasterized image
data is only stored by the graphic image server in compressed form,
substantially reducing the memory requirements for the output queue. Using
a compression scheme such as run length coding, compression on the order
of 100:1 can be achieved, although lower compression ratios are more
typical. Even with lower compression ratios, the amount of RAM or hard
disk space required can be significantly reduced. Once the compressed data
is output from RAM 32 to interface 38, it is immediately decompressed for
further output to the output device. In this manner, the benefits of
compression are achieved completely independently of the output device.
There is no need to require the output device to have a decompression
stage, and no need to accommodate any particular decompression
requirements that might otherwise be mandated by the output device.
The interface of the present invention can additionally provide
bidirectional compression. For example, if output device 16 (FIG. 3) is a
copier, it may have the capability of scanning a document and outputting
digitized image data. This image data can be communicated via bus 52 and
I/O control 42 back to compression processor 40. The compression processor
will process the scanned image data in accordance with a known compression
scheme, such as run length coding. The compressed data will then be
communicated via output port 36 (functioning as a bidirectional port) to
RAM 32 or hard disk 30, which stores the compressed data in an appropriate
input queue for subsequent output to another device such as graphics
processor 26.
I/O control 42 can comprise a microprocessor that controls the flow of data
between the various components of the interface 38. It will be understood
that control lines (not shown) interconnect I/O control 42 with the
various other components of the interface. Also not illustrated are
conventional power supply lines.
I/O control 42 also enables page oriented output devices (e.g., color
copier print engines) to be driven at their maximum rated speed. As
indicated above, most mechanical print engines have a first copy out delay
period during which various mechanical parts are brought up to speed and
prepared for producing images. In accordance with the present invention,
I/O control 42 enables different successive images output from the
interface to be processed by such print engines in a continuous run
without returning to an idle state between each different image. This is
accomplished by taking advantage of the fact that such print engines are
able to make multiple copies of the same image.
Such print engines, typically found in copiers and laser printers, allow an
operator to specify a number of copies to be made. For example, where
copies are made by placing an original document on a platen, the operator
can specify that he wants, e.g., one hundred copies of that document. The
copier will then proceed to make continuous copies of the same document
until the desired number of copies has been provided.
Taking advantage of this multiple copy feature, the I/O control 42 of the
present invention will instruct the output device 16 to make the maximum
number of multiple copies that the output device is capable of making,
when the first image is forwarded to the output device for reproduction on
a substrate. The output device will then continue to run at its maximum
rated speed, with the interface providing a new set of rasterized image
data for each subsequent copy made. The output device proceeds on the
assumption that it is making multiple copies of the same image, even
though it may actually be making a single copy of each of the different
images forwarded thereto by the interface 38.
Unfortunately, the interface may not know in advance the exact number of
images it will be sending to the output device. For example, if a document
is described in a language-like PostScript, then the total number of pages
will not be known until the document is completely processed. It would be
far more convenient to print the document page by page, rather than having
to completely process it before beginning to print it. Another situation
that can create difficulty is where one or more pages of a multi page
document carries a particularly complex image. Ideally, the graphic file
server should be able to produce the pages as fast as the output device
requires them. If a complex page causes the graphic file server to slow
down and be late, the output device may produce an extraneous page if it
is merely set to make continuous copies. Since neither the graphic file
server nor the interface know the number of pages that are going to be
sent to the output device in advance, and cannot predict when a page will
be late due to processing complexity, it is impossible to simply send the
output device a reliable count of the number of pages to be produced.
In order to overcome this problem, I/O control 42 provides an "abort"
command to the output device. As indicated above, the I/O control
initially instructs the output device to produce a large number of
consecutive copies, e.g., the maximum number of continuous copies that it
is capable of producing. The interface 38 will then begin sending raster
image data for each successive page to be produced. In the event that the
interface runs out of output images to send before the copy count to which
the output device has been set is reached, an abort command is sent by the
I/O control 42 to the output device. Another copy count and start command
would be sent to the output device when additional images are available
from the graphic image server.
The specific implementation of the abort command must account for any
inability of the output device to stop immediately. For example, due to
mechanical constraints the output device may have already started a new
substrate (e.g., piece of paper) in motion by the time the I/O control
sends the abort command. This would produce an undesirable blank page at
the end of the run. Thus, for such an output device it would be necessary
to send the abort command one or even two pages in advance of the point at
which the last page of rasterized image data is forwarded via output data
bus 52. In order to accomplish this, provision is made by I/O control 42
for synchronization of the timing of the abort command with the mechanical
cycle of the output device. It should be appreciated that the specific
timing of the abort command will generally be different for each different
type of output device.
An example of the abort command timing is illustrated by time line 70 in
FIG. 5. The production of images by the output device 16 commences at
point 72 when I/O control 42 sends a start command to the output device
via bus 52. Thereafter, at a point designated by reference numeral 74, the
I/O control sends the output device 16 a multiple copy command,
instructing the output device to commence a continuous run of a large
number of copies. At the same time, the decompressed rasterized image data
for a first page P1 is forwarded from decompression subsystem 44 to the
output device 16 via data bus 52. Rasterized image data for subsequent
pages (P2, P3, . . . PN) are consecutively sent to the output device from
the decompression s | | |
