Methods and systems for processing image data

Details Methods and systems for processing image data Methods and systems for processing image data

1999-04-14

2004-05-18

Williams, Kimberly (Department: 2626)

Facsimile and static presentation processing

Static presentation processing

Character or font

C358S001150, C345S215000, C345S215000, C400S708000, C400S076000

Reexamination Certificate

active

06738150

ABSTRACT:

FIELD OF THE INVENTION
This invention pertains to methods and systems for processing image data.
BACKGROUND OF THE INVENTION
In the past, printers have typically captured an entire page before any image is placed on paper. In such printers, formatting is either performed on the host computer (with large volumes of rasterized data being shipped to the printer), or on a formatter within the printer. Since a laser printer print engine operates at a constant speed, if new rasterized data is not available at a rate that keeps up with the engine's operation, a print “overrun” occurs and the page is not printable. Various methods for addressing print overrun situations are described in U.S. Pat. No. 5,479,587, the disclosure of which is incorporated by reference herein. Various other aspects of printers are described in the following U.S. patents, the disclosures of which are incorporated by reference: U.S. Pat. Nos. 5,450,562, and 5,459,818.
For purposes of understanding various problems associated with past processing techniques relative to printers and the like, a somewhat high level block diagram describing a system configured to process image data is shown generally at
20
in FIG.
1
. System
20
typically includes a so-called image pipeline which processes image data provided by a host into a form which is suitable for use by a printer engine. The image pipeline comprises a number of different elements which can be implemented in any suitable hardware, software, or firmware. In this example, image pipeline
22
includes an interpreter
24
, a graphics engine
26
, a canvas
28
, and an image processor
30
. An engine
32
is provided and comprises, in this example, a print engine such as would be found in a laser printer.
Typically, an image or a file gets sent to system
20
via an I/O port (not specifically designated). In a typical personal computer scenario, a print job will load through an operating system such as Windows, to a driver and will be sent out a parallel port. The print job need not, however, come from a personal computer. Rather, it can come from a mainframe, from work stations, or from other devices. In addition, it need not have parallel porting. Rather, it can come through infrared ports or LANs that show other I/O type ports, to name just a few. The print job is received by interpreter
24
which then operates upon the print job in a known manner. At the interpreter level, the print job is parsed and a job stream is formed to determine what operations are being specified. Interpreter
24
is in communication with graphics engine
26
and communicates to the graphics engine what operations are being specified. Graphics engine
26
operates on information received from interpreter
24
by doing such things as ensuring that the information does or does not have to be clipped, Additionally, if a particular structure specified by interpreter
24
needs to be filled, it determines what area has to be filled and the like. If a particular structure specified by interpreter
24
needs to be stroked, it determines what area and what objects are to be used for stroking.
Canvas
28
is provided and is in operable contact with graphics engine
26
. The graphics engine
26
sends the resulting object to canvas
28
for processing. The graphics engine
26
communicates to canvas
28
a description of the object it has operated upon. Canvas
28
breaks up information received from the graphics engine into smaller amounts of data. In this example these smaller amounts of data are known as strips. Accordingly, at the canvas level, work requests are built and each work request is associated to a strip.
Image processor
30
is coupled with canvas
28
and will eventually receive the work requests from canvas
28
and start imaging them or rendering them into bits. The rendering of strips into bits results in formation of a raster bit map. The raster bit map is used to drive print engine
32
for rendering an image. The above description constitutes but one exemplary system which can be utilized to process image data into a form suitable for use by a print engine. More detailed information about the operation of systems, such as system
20
, can be found in the patents incorporated by reference above. In addition, while the interpreter
24
, graphics engine
26
, canvas
28
, and image processor
30
are shown as discrete elements, such need not be the case.
Problems can occur in the image pipeline because of the different nature of the information or data the elements process. For example, problems can occur at the graphics engine
26
and canvas
28
levels pertaining to the complexity levels at which each element is designed to handle the associated data it receives. For example, canvas
28
works at a fairly low primitive level. Hence, optimal or desirable operation within the canvas functionality is attained when the information or data received thereby is in a very simple format. The graphics engine
26
, on the other hand, operates at a fairly high level or in a very sophisticated format. Resultingly, in the translation from the sophisticated format of graphics engine
26
to the simplistic format of canvas
28
, one can experience a data explosion.
For example, at the top end of graphics engine
26
, one may be directed to draw a circle which is specified by a point and a radius. At the bottom end of graphics engine
26
, canvas
28
does not understand that particular definition of a circle, so the circle definition is broken into a number of so-called trapezoids through processing techniques known as polygon decomposition. Accordingly, the circle is broken into n number of primitives. Those primitives can be rectangles, trapezoids, and what are referred to as x and/or y line scans. Hence, a typical circle might break into perhaps 200 or 300 basic objects. This is where a real problem can occur because, essentially, a data explosion results by converting from one format to another.
Prior solutions to the above-identified problems have included compressing raster data across the I/O interface and/or tuning the image pipeline to keep up with existing I/Os, but not placing constraints on the raster image data coming into the printer.
With respect to the compression solutions, such can, in some instances, involve simply taking an image or a page-ready scan, and compressing it with little or no understanding of what device will be used to ultimately process it. In this instance, no optimization is used at all since, simply, a blind compression of the image is conducted which is subsequently sent off to the printer or scanner. Accordingly, the device must then decompress the compressed data and operate upon it to get it ready for the imaging pipeline. Disadvantages to this solution are that to print the raster data at an appropriate engine speed, additional hardware is required at, the data source and in the printer to perform compression and decompression. Additionally, some source images, especially halftoned scanned data can be “noisy” and may not compress very well. As a result, many of these types of pages will not print at engine speed.
With respect to the tuning of the image pipeline without constraining raster image data, such typically involves the device itself getting involved in the breaking of the image into strips, insuring that the data is properly clipped and/or otherwise processed. Hence, every time a pixel is manipulated by the device, the whole system slows down. This can significantly slow throughput. A disadvantage of this approach is that more processing, and hence overhead, is required in the printer to format the data into engine-ready format. A faster printer controller would be needed to keep up with I/O rates of 7.5 MB/sec than what is currently used in some current 32 page-per-minute (ppm) wide-format printer engines.
Accordingly, this invention arose out of problems associated with improving the efficiency with which high-bandwidth image data is handled in a peripheral unit's, and particularly a printer's image pipeline.
SUMMAR

Affiliated with

Also associated with

Rating

Methods and systems for processing image data does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Methods and systems for processing image data, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Methods and systems for processing image data will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-3211817