|Publication number||US5274794 A|
|Application number||US 07/643,738|
|Publication date||Dec 28, 1993|
|Filing date||Jan 22, 1991|
|Priority date||Jan 22, 1991|
|Publication number||07643738, 643738, US 5274794 A, US 5274794A, US-A-5274794, US5274794 A, US5274794A|
|Inventors||Bland Ewing, William A. Eckert|
|Original Assignee||Graphon Corporation|
|Export Citation||BiBTeX, EndNote, RefMan|
|Patent Citations (7), Referenced by (22), Classifications (7), Legal Events (8)|
|External Links: USPTO, USPTO Assignment, Espacenet|
The effective encoding and transmission of XY coordinate data between a host computer and a graphics display device has long been an issue in computer graphics. Generally, each XY coordinate is encoded into a short stream of bytes which is then transmitted to the display device. Many schemes have been developed to encode these coordinates, some with the goal of maintaining human readability, others with the goal of simple decoding by hardware logic in the receiving device.
Conventional hardware oriented implementations use groups of bits in transmitted bytes to hold partial XY coordinate data. The receiving device accumulates bits from several bytes to obtain a complete XY specification. Some of these conventional methods use one or two bits in each byte to specify which parts of the XY coordinate are represented by the other data bits. While such conventional methods can be fairly compact, They are most efficient when dealing in numbers which are powers of two because fixed numbers of bits can be dedicated to representing each of the X and Y values.
As graphic systems have increased in performance, users' expectations for that performance have increased. However, the transmission media currently available to transfer data from a host computer system to a graphics display device vary greatly in bandwidth, ranging from thousands of bits per second to tens of millions of bits per second. The most readily available and least expensive communications media are at the low end of that range. Meeting high performance expectations over a low bandwidth transmission line requires very efficient encoding of XY coordinate data.
Another consideration in sending XY coordinate data to a receiving system is that the data is often sent over a communications path which puts restrictions on the byte values that may be transmitted. For example, the characteristics of the communications path may be such that either 7 or 8 bits of each byte are accessible to the sender and receiver. Thus, the encoding scheme must be able to function in environments where the magnitude of the value transmitted in each byte may be either 28 =256 or 27 =128. In practice, the range of values which a byte may take is reduced even further, as some specific values may be reserved for system and other uses.
The present invention provides a method and apparatus for the efficient encoding of absolute XY data, that involves combining XY (and possibly additional) data into a single value using a mixed radix polynomial. This value is fully independent of the characteristics of the communications path, and can be broken down into a number of bytes which are compatible with the communications path. This is done using a fixed radix polynomial. The result is a smaller number of bytes being transmitted than is generally possible with existing encoding schemes, in practice as few as three bytes for a 2560×2560 pixel display, using only 190 of the 256 values available in an 8-bit byte.
The encoding is based on the vertical and horizontal resolution of the graphics bitmap. Resolutions need not be a power of two, and the bitmap being addressed need not have a 1:1 aspect ratio. For example, a bitmap with a resolution of 800×600 can be accommodated efficiently. The maximum resolution which can be encoded is unlimited in theory, and in practice is limited only by the ability of the sending and receiving devices to perform sufficiently long multiplications and divisions efficiently.
The present invention adjusts to the resolution of the XY coordinates being transmitted and lower resolution bitmaps can be addressed by transmitting fewer bytes of data than must be sent for higher resolution bitmaps.
Fewer bytes than necessary to address the entire bitmap may be sent whenever it is permissible to address only a sub-window of the bitmap. The encoding scheme requires that each encoded number includes a limited range of values between 0 and a positive maximum. However, by applying previously established offsets to the coordinates before they are encoded, and removing the offsets after they are decoded, this sub-window may be located anywhere in the larger bitmap. With use of correct offsets, any contiguous range of negative and/or positive integers may be encoded.
It is also possible to encode coordinates with resolutions higher than those of the on-screen bitmap. This is useful when addressing a larger bitmap which is displayed on a small screen acting as a viewport which may be moved around the larger bitmap by the user, without forcing the retransmission of graphic data as the viewport is moved. It also allows a low resolution device to display a portion of an image created for display on a higher resolution device.
Once the sending and receiving devices have determined the number of bytes required to encode an arbitrary XY coordinate, it is usually the case that an additional value can be encoded without increasing the number of bytes required. This can be used, for example, to allow graphics commands to be encoded into the XY data without incurring any additional transmission overhead. Multiple additional values can be encoded if so desired.
In general, the coordinate system encoded according to the present invention may be n-dimensional. The data being encoded may include coordinates for two or three dimensional graphics data, as well as other data. The encoded data need not include XY or XYZ coordinate data at all, but rather may include any finite set of values whose members have finite ranges. Examples include the encoding and decoding of XY coordinates and a color, or XYZ coordinates and a color, or XYZ coordinates and a color and one or more commands such as, for example, a command to draw a circle, the XY coordinates of its center, the length of its radius, its color, the width of the line used to draw it, and an index into a list of patterns for that line.
The transmitted data can be packaged in such a way that transmission paths which can handle 7 or 8 bit bytes can be used efficiently, and the bytes that are created can avoid certain ranges of codes, for use in transmitting non-XY data.
The encoding scheme compresses many types of data better than a simple ASCII encoding, but also better than even the "binary" information stored on mass storage devices A single instance of a variable of the enumerated type of the Pascal computer language is generally stored as a 16-bit value in a binary file. Using this encoding, only the number of states of that enumerated type is encoded, generally allowing many enumerated types to be stored in a very small number of bytes. A single byte could hold up to five of these variables having three states apiece--a binary file would generally save these in ten bytes.
The present invention is effective for use over communications paths of any bandwidth, and to and from mass storage and retrieval systems. While the examples show transmission over a byte-wise communications path, it will adapt to a path of any width, including local busses within a computer.
FIG. 1 is a block schematic diagram of the system according to one embodiment of the present invention for communicating processed data over ASCII-compatible, byte-oriented channels;
FIG. 2 is a flow chart illustrating the initialization process for an encoding/decoding system according to the present invention;
FIG. 3 is a flow chart illustrating the computation logic according to the present invention;
FIG. 4 is a flow chart illustrating the process for encoding XY coordinate data and a command table index, C, for transmission to a graphics display device; and
FIG. 5 is a flow chart illustrating the process for decoding encoded XY and C data according to the present invention.
Referring now to FIG. 1, there is shown a flow chart illustrating an embodiment of the present invention in a bit-mapped graphics terminal and in corresponding software running in a host computer, communicating over a communications path which transmits ASCII-compatible, byte-oriented data. The encoding scheme is used to encode two dimensional XY coordinate data with a third value, called C.
In operation, the host computer 1 causes graphic data to be displayed on the screen 17 of a remote graphics display device 3. The processor 7 operating under program control 5 generates graphics data in conventional manner, for example, from image data, in a `windows` operating system to be sent to the graphics display device in the form of vectors, filled rectangles, positioning information for text strings, and the like. The processor 7 in the host computer 1 controls the encoding 9 of each pair of XY coordinates with an index C into a table of graphics commands. The data is encoded 9 in conventional manner, for example, under program control of processor 7 such that the resulting bytes do not include any instances of bytes in the ranges of ASCII control codes.
These encoded coordinates and graphics commands are then transmitted 14 to the graphics display device 3 which includes processor 11 that controls the decoding 13 in conventional manner, for example, under program control of processor 11, of the coordinates and the index C into the table of graphics commands. Of course, the processors 7 and 11 may comprise the same processor in a system in which the proximate location of host computer 1 and device 3 permit sharing of the common processor. The command index and the XY coordinates are passed to the graphics driver 15 of convention design which draws the correct vector, filled rectangle, and the like, for example, under program control of processor 11, into the bitmap for display on the screen 17.
Alternatively, short or long term storage of the encoded data may occur in a mass storage and retrieval system 19, without the encoded data being sent to the graphics display device, for access by the host computer 1, or by an alternate host computer (not shown), or for access by the graphics display device 3, as shown.
The ranges of X and Y may be equal to the horizontal and vertical resolution of the bitmap to be addressed (which is usually, but not necessarily, the entire bitmap as displayed on the graphics display device's CRT). The range of C is limited to that which will encode into the outgoing data without requiring that an additional data byte be sent. However, if its range is large enough, C may be transmitted "for free" with each outgoing XY coordinate.
In this embodiment, C may be used to encode mode switching commands into the XY data. For example, one value of C indicates that the following XYs are to be used to draw vectors, while another value of C specifies that the following XYs are to be used to draw filled rectangles.
Referring now to FIG. 2, there is shown a flow chart illustrating the process for the initialization of the encoding/decoding system of FIG. 1 according to the present invention. The host computer 1 either knows the resolution of the graphics display device 3, or it must query 21 the device for that information. With the refined report 22 of the resolution of the destination display 3, or with that information previously provided, the host computer 1 saves the resolution in Xres and YRes. The host computer 1 then determines the area, or "sub-window" of the bitmap into which it wishes to draw, saving the size of the sub-window in XSize and YSize and saving 23 the coordinates of the origin of the sub-window in XOrigin and YOrigin. Additionally, the host computer 1 also receives information about whether the communications path 24 is capable of transmitting 7- or 8-bit bytes of data.
The host computer 1 then sends to the graphics display device 3 the parameters to be applied in the encoding and decoding process 25. It sends the resolution in X and Y of the window on the screen into which the host computer 1 wishes to draw, called XSize and YSize. In addition, the host computer sends the origin of that window, called XOrigin and YOrigin, allowing it to be placed at the desired location in the bitmap of the display device. Also, the host computer 1 sends Radix, which is the magnitude of the value that is contained in each byte sent over the communications path 24. This initialization process may be repeated at any time during the drawing of single or multiple graphics images, redirecting the drawing commands to different sub-windows to maintain an optimally compact stream of coordinate data.
Now that both sender and receiver have the necessary parameters, they can each determine the number of bytes which are to be sent for each pair of XY coordinates. This is accomplished, as illustrated in FIG. 3, by multiplying XSize and YSize together 31 giving MaxVal. MaxVal is the minimum value which must be transmitted to allow all necessary values of X and Y to be encoded. Next, the minimum number of bytes which must be transmitted to send MaxVal is computed by repeatedly dividing MaxVal by Radix 33 until MaxVal becomes zero. The number of divides executed is saved as NBytes, which is the minimum number of bytes required to transmit an XY coordinate. Finally, the maximum value of C which may be encoded in NBytes bytes is computed 35 by raising Radix to the power of NBytes. Dividing this value by XSite * YSite subtracting 1 gives the remaining component of the transmitted value 35 that is available for encoding C.
For example, the graphics display device 3 may report to the host computer that its bitmap display 17 has a resolution of 800×600 pixels. The host computer 1 wishes to draw into the entire bitmap. The communications path 24 between the host 1 and the display device 3 can carry 8-bit data and the encoding scheme should avoid generating ASCII control codes (in the range of binary values 0 through 31, 127 through 159, and 255). Of course, other conventional computer codes such as EBCDIC may also be used, most of which have different but analogous codes which must be avoided. The host computer 1 then communicates 25 to the display device 3 that XY coordinates will be sent with a magnitude of X (XRes=800) and Y (YRes=600), that the offset to the origin of the coordinate space over the bitmap is (0,0)(XOrigin=0, YOrigin=0), and that transmitted bytes will contain values 0 through 189 offset so that ASCII control codes are never transmitted. (Radix=190). Each device 1, 3 then determines that three bytes must be transmitted to define a single XY location, and that C may take on values of 0 through 13.
Once the system is initialized, XY coordinate data and a command table index C may be encoded for transmission to the graphics display device 3 as shown in FIG. 4. To encode the X, Y and C values, first the coordinate space of the display window 17 is shifted so that X and Y values of 0, 1, 2 . . . are transmitted 41. Then, Value is determined by solving a mixed radix polynomial 43. The general form of the polynomial is: ##EQU1##
"Value", which is unique for all valid values of X, Y and C, is then divided into NBytes bytes using the following fixed radix polynomial: ##EQU2##
In this embodiment, the polynomial is solved by dividing Value by Radix a number (NBytes) of times. Each time, the quotient is placed back into Value, and the remainder is placed in OutByte 45, then offset 47 by adding 32. This puts OutByte out of range of ASCII control codes 0 through 31. If OutByte is less than 127, it is in the range of ASCII graphic codes 32 through 126 and it can be sent to the graphics display device. If OutByte is 127 or greater, it is offset 49 again by adding 33, which ensures that it will not be an ASCII control code 127 through 159, and moves it into the range of ASCII graphic characters 160 through 254. The ASCII code 255 is avoided by the proper choice of Radix and by encoding only valid values of X, Y, and C. The altered byte in OutByte is then sent 51 to the graphics display device 3. This process is repeated until NBytes bytes have been sent by the host.
Offsetting each byte in this manner leaves the control codes of the standard ASCII character set free for use as commands rather than as XY data.
Continuing the example using the 800×600 pixel coordinate space, the host computer 1 may wish to encode the coordinates (for example, 757,144) with a command which is specified by encoding a C value of 2. First, it subtracts the origin (0,0) leaving the coordinates unchanged at (757,144). Then, it applies the polynomial from Eq. 1:
With this value for Value, byte1 through byteNBytes can be determined according to the polynomial (from Eq. 2) using the repeated division described above: ##EQU3##
Thus, in this example, the coordinates (757,144) and the C value of 2 encode to three bytes with values 239,65,71. Referring now to FIG. 5, the flow chart illustrates the reverse steps executed by the graphics display device 3 to decode the data sent by the host computer 1 into X, Y and C. First, the display device 3 receives NBytes bytes via the communications path 24. As each byte is received, it is placed in a variable called Byte 61. The offsets which were added in the encoding step to ensure that no transmitted bytes were in the range of ASCII control codes are now removed 63. Then Byte is placed in a receive buffer, called InputArray 65, in reverse order, that is, the first byte received is put in the last position in the buffer, and so on.
Once NBytes bytes have been loaded into InputArray 65, the variable value is initialized to zero and the array index variable j is initialized 67 to zero. Then a loop 69, 71 is entered to process each byte in InputArray. Each time through the loop, Byte is loaded by pulling a byte out of InputArray at index j and j is incremented 69 by 1. Value is multiplied by Radix and Byte is added 71 to it, yielding a new value for Value. These steps are repeated NBytes times, until each received byte is processed. The resulting Value is the same as the value of Value determined when the coordinates were encoded in the host computer 1.
Value is then broken down into its component X, Y and C parts according to the polynomial (from Eq. 1) above. When Value is divided 73 by YSize, the remainder is Y. When the quotient is further divided 75 by XSize, the remainder is X and the quotient is C. Finally, X and Y are translated 77 by adding the coordinates of the origin of the transmitted coordinate space over the destination bitmap.
In another embodiment of the present invention in which a mass storage and retrieval device 19 is used to hold the encoded data, the form in which the data is stored would depend upon the final use of that data. If it is being stored for subsequent transmission to a remote display device, it may be stored exactly as generated or encoded according to the preceding description. If instead it is to be recalled by the originating host computer for use without having to be transmitted over a restrictive data path, then the intermediate values (called Value, above) for the XY may be stored without breaking it up into bytes, as described above, for transmission. Using numeric data from the example above, the sample XY could be stored as the three byte values 239,65,71 or as the single number 1,414,344. Depending on how large numbers are stored by and retrieved from the mass storage and retrieval device, it may be more compact and efficient to store the three-byte values.
The variables required to encode and decode each X, Y, and C as described in this embodiment are XSize, XOrigin, YSize, YOrigin, MaxC, Radix, and NBytes. (The origin of C is fixed at zero.) If the transmitting and receiving devices keep a set of these eight variables for each of multiple windows, it becomes possible to change encoding on the fly, window by window. Generalizing this for an n-dimensional system requires that the devices keep 2n+2 variables per window.
|Cited Patent||Filing date||Publication date||Applicant||Title|
|US4797945 *||Dec 11, 1986||Jan 10, 1989||Canon Kabushiki Kaisha||Image data coding apparatus|
|US5047853 *||Mar 19, 1990||Sep 10, 1991||Apple Computer, Inc.||Method for compresssing and decompressing color video data that uses luminance partitioning|
|US5049992 *||Aug 27, 1990||Sep 17, 1991||Zenith Electronics Corporation||HDTV system with receivers operable at different levels of resolution|
|US5058185 *||Jun 27, 1988||Oct 15, 1991||International Business Machines Corporation||Object management and delivery system having multiple object-resolution capability|
|US5115809 *||Mar 29, 1990||May 26, 1992||Kabushiki Kaisha Toshiba||Ultrasonic probe|
|US5131057 *||Feb 12, 1990||Jul 14, 1992||Wright State University||Method for video-to-printing image resolution conversion|
|US5185883 *||Oct 26, 1990||Feb 9, 1993||Data Translation, Inc.||System for locating failure signals by comparing input data with stored threshold value and storing failure addresses in alternating buffers|
|Citing Patent||Filing date||Publication date||Applicant||Title|
|US5764235 *||Mar 25, 1996||Jun 9, 1998||Insight Development Corporation||Computer implemented method and system for transmitting graphical images from server to client at user selectable resolution|
|US5968182 *||May 12, 1997||Oct 19, 1999||International Business Machines Corporation||Method and means for utilizing device long busy response for resolving detected anomalies at the lowest level in a hierarchical, demand/response storage management subsystem|
|US6501472||Mar 6, 1998||Dec 31, 2002||Insight Development Corporation||Method and system for transmitting graphical images|
|US6823016 *||Feb 20, 1998||Nov 23, 2004||Intel Corporation||Method and system for data management in a video decoder|
|US6950101||Dec 23, 2002||Sep 27, 2005||Research Investment Network, Inc.||Computer implemented method and system for transmitting graphical images from server to client at user selectable resolution|
|US6965442 *||Aug 24, 1998||Nov 15, 2005||Brother Kogyo Kabushiki Kaisha||Document information communicating system|
|US7672372||Feb 24, 2003||Mar 2, 2010||Intel Corporation||Method and system for data management in a video decoder|
|US7716598 *||Apr 1, 2008||May 11, 2010||Microsoft Corporation||Resizing internet document for display on television screen|
|US7925689 *||Jul 30, 2002||Apr 12, 2011||Kwok, Chu & Shindler Llc||Method and system for providing on-line interactivity over a server-client network|
|US7970818||Aug 30, 2006||Jun 28, 2011||Kwok, Chu & Shindler Llc||Method and system for providing on-line interactivity over a server-client network|
|US8073900 *||Aug 30, 2006||Dec 6, 2011||Intellectual Ventures I Llc||Method and system for providing on-line interactivity over a server-client network|
|US8483290||Jan 14, 2010||Jul 9, 2013||Intel Corporation||Method and system for data management in a video decoder|
|US8725645||Feb 13, 2013||May 13, 2014||Cetrus LLC||Non-invasive metering system for software licenses|
|US8988418||Jul 2, 2012||Mar 24, 2015||Florelle, Inc.||System and method for parametric display of modular aesthetic designs|
|US20030072299 *||Dec 23, 2002||Apr 17, 2003||Hunt William J.||Method and system for transmitting graphical images|
|US20030088609 *||Jul 30, 2002||May 8, 2003||Mgi Software Corporation||Method and system for providing on-line interactivity over a server-client network|
|US20070052617 *||May 2, 2006||Mar 8, 2007||Palm, Inc.||Moveable output device|
|US20070112857 *||Aug 30, 2006||May 17, 2007||Guedalia Jacob L||Method and system for providing on-line interactivity over a server-client network|
|US20070136374 *||Aug 30, 2006||Jun 14, 2007||Guedalia Jacob L||Method and system for providing on-line interactivity over a server-client network|
|US20080184163 *||Apr 1, 2008||Jul 31, 2008||Microsoft Corporation||Resizing internet document for display on television screen|
|US20100111164 *||Jan 14, 2010||May 6, 2010||Hungviet Nguyen||Method and System for Data Management in a Video Decoder|
|EP0697613A2 *||Aug 14, 1995||Feb 21, 1996||Sony Corporation||Cyber-space system|
|International Classification||G06F3/14, H04L29/06|
|Cooperative Classification||H04L29/06, G06F3/14|
|European Classification||G06F3/14, H04L29/06|
|Jan 22, 1991||AS||Assignment|
Owner name: GRAPHON CORPORATION, 1980 CONCOURSE DRIVE, SAN JOS
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST.;ASSIGNORS:EWING, BLAND;CKERT, WILLIAM A.;REEL/FRAME:005586/0470
Effective date: 19910121
|Aug 14, 1995||AS||Assignment|
Owner name: TATUNG COMPANY, TAIWAN
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:GRAPHON CORPORATION;REEL/FRAME:007588/0265
Effective date: 19950809
|Aug 5, 1997||REMI||Maintenance fee reminder mailed|
|Dec 8, 1997||SULP||Surcharge for late payment|
|Dec 8, 1997||FPAY||Fee payment|
Year of fee payment: 4
|Jul 24, 2001||REMI||Maintenance fee reminder mailed|
|Dec 28, 2001||LAPS||Lapse for failure to pay maintenance fees|
|Mar 5, 2002||FP||Expired due to failure to pay maintenance fee|
Effective date: 20020128