Method for Converting a Bit Map of an Image to a Run Length or Run End Representation

1. Field of the Invention

The present invention relates to digital image processing methods and more particularly to methods for converting an image from a bit map representation to a run end or run length representation.

2. Description of the Prior Art

The following is a system representative of the prior art.

"A Method for Converting a Bit Map of an Image to a Run Length or Run End Representation", U.S. Pat. No. 4,610,027 to Anderson et al, shows a method for converting a bit map representation of an image to a run representation of an image, the method to be executed on a computer system which has the facility to perform shift operations and table look-ups in a relatively short time with relatively few machine cycles.

The method of the present invention is a modification and an improvement upon the prior art for execution on small systems, efficiently using the capabilities of small processors to convert images from bit map representations to run representations.

The prior art discussed above does not teach nor suggest the present invention as disclosed and claimed herein.

Therefore, it is an object of the present invention to convert an image from a bit map representation to a run end or run length representation by a method including the steps of: accessing for each byte in an image by a lookup table a selected routine, corresponding to such byte, from a number of routines for converting bit strings to run representations; executing the selected routine on the current byte to convert the bit string to a run representation; storing, in a run representation buffer, as a count value, each run representation; and repeating the steps of accessing and executing for each byte and storing for each run of continuous color to the end of the image.

It is another object of the present invention to convert an image bit map to a run end or run length representation by a method as above wherein the step of accessing further includes the step of: addressing a first lookup table with a current image byte if a last image bit has a first value; and addressing a second lookup table with a current image byte if a last image bit has a second value.

It is yet another object of the present invention to convert an image bit map to a run end or run length representation by a method as above wherein image bytes having more than a predetermined number of runs are converted to run representations by a bit by bit trellis routine.

It is yet another object of the present invention to convert an image bit map to a run end or run length representation by a method as above wherein image bytes having more than a predetermined number of runs are converted further including the step of: inputting a current image byte to a first starting point in a trellis routine if a last image bit is a first color; and inputting a current image byte to a second starting point in a trellis routine if a last image bit is a second color.

Accordingly, a method for converting an image from a bit map to a run end or run length representation includes the steps of: storing the image as a bit map representation; accessing for each byte in an image by a look-up table a selected routine, corresponding to such byte, from a number of routines for converting bit strings to run representations, wherein the look-up table accessed is selected in accordance with a color value of a preceding pixel binary bit; executing the selected routine or the current byte to convert the bit string to a run representation; storing in a run representation buffer, as a count value, each run representation; and repeating the above steps of accessing and executing for each byte and storing for each run of continuous color to the end of the image.

It has been determined that in a typical image approximately 98% of image bytes have three or fewer runs and that this 98% of the image bytes include 60 byte patterns which may be preceded by a white bit or by a black bit requiring 120 table entry points plus one table entry point for an end of line code for a total of 121 entry points. This 98% is processed from bit string representation to run representation in an efficient and fast manner in accordance with the present invention. The remaining 2% of the image bytes which have four or more runs therein are processed by a trellis routine having a first entry point for bytes with a previous white bit and a second entry point for bytes with a previous black bit.

It should be noted that each of the image bytes having three or fewer runs has a unique routine for processing the bit string to a run representation whereas the remaining image bytes having four or more runs are all processed by a common routine which differs only in the entry point determined by the color or a previous bit in the image.

It is a feature of the present invention that image data may be rapidly converted from bit string representation to run representation in a small processor such as a microcomputer by a method as above which takes maximum advantage of the processor capabilities of a microcomputer to speed execution of the conversion of an image from bit strings to run representations.

The foregoing and other objects, features and advantages of the invention will be apparent from the more particular description of the preferred embodiments of the invention, as illustrated in the accompanying drawing.

FIG. 1.1 is a schematic diagram of the first step in the method according to the present invention for processing an image byte following a white bit.

FIG. 1.2 is a schematic diagram of the first step in the method according to the present invention for processing an image byte following a black bit.

FIG. 2 is a flow diagram showing specific routines for conversion of selected image bytes having three or fewer runs.

FIG. 3 is a flow diagram of a trellis routine for processing image bytes having four or more runs.

In the drawing, like elements are designated with similar reference numbers, and identical elements in different specific embodiments are designated by identical reference numbers.

The method according to the present invention adddresses the problem of using an IBM Personal Computer to quickly convert a binary image represented as a bit map (8 bits/byte) in storage into a series of vectors of run ends or run lengths (one vector for each line of image data and each vector containing one or more run end or length representations). The run ends are the displacements in bits (i.e. picture elements or pels) from the left edge of the image to the last pel in each run.

The present method uses a novel combination of techniques to produce code which is significantly faster than prior art methods. These include:

1. Using a lookup table to locate the code for processing any image byte, implicitly selecting which of a number of routines is most appropriate for processing that byte's bit pattern;

2. Explicitly coding the steps to be followed to process the bytes which occur most frequently in typical images;

3. Applying a more general (but still reasonably fast) routine to process most other possible image bytes;

4. Forcing processing at the right edge of the line into a rarely used path to avoid frequent testing for the end of a line of image data; and

5. Exploiting the fact that a binary image typically includes large areas containing only zero (white) picture elements.

The prior art describes the fifth technique (which uses the scanning instruction available on many processors to find the length of a long sequence of zero bytes relatively quickly), an alternative method of applying the fourth technique, and the procedures which control the conversion (trimming, padding, etc.).

In the IBM System/370 the ratio of the execution time of a branch to that of a lookup is approximately 21/2 to 1 and the ratio of a branch to any shift is approximately 4 to 1. In an IBM Personal Computer the cost of a lookup is slightly higher than the cost of a branch, and a shift by a variable number of bits costs 3/4 of a branch for a shift by 1 bit, 1 branch for a shift by 2 bits, 11/4 branches for a shift by three bits, etc. It is therefore much more important in an IBM Personal Computer to minimize lookups and variable shifts, even at the cost of requiring more code space. It is also advantageous to make use of the operations which an IBM Personal Computer can perform very quickly, such as shifts by a single bit (1/8 of a branch) and additions of constant values to registers (1/4 of a branch). The method described herein is designed to avoid extensive use of instructions which are very time-consuming to execute on an IBM Personal Computer.

The preferred embodiment of the present invention generates a run end representation of the image data. It could be adapted to produce a run length representation if required.

The preferred embodiment creates a run end buffer for each line which contains a series of halfwords. The 16 bits in the halfword are adequate to represent images with widths up to 32K as positive displacements. The first halfword in each line buffer gives the number of bytes of run end data plus two bytes for the count (i.e. the total number of bytes of data in the buffer); this is followed by three zero run ends, an arbitrary number of pairs of white/black run ends, and two additional copies of the last black run end. If the image row begins with a black run, the first white run end must be specified as zero. If the image row ends with a white run, the last black run end will be the same as the last white run end, so that we in fact have three additional copies of the last real run end. For example, if no skipping or padding is specified, the three-line bit image in which a black bit is represented by a binary 1 and a white bit is represented by a binary 0:

would produce three vectors with the following halfword entries:

The conversion method according to the present invention (see FIGS. 1.1 and 1.2) operates by reading a byte of image data, using it to index into one of two lookup tables (see Tables I and II below) to obtain the address of the routine which is to be used to process the byte, and then branching to that address. There are two tables because the bit preceding the byte being processed may be either white (0) or black (1); if the first bit of the new byte is not the same color as the preceding bit, then the first bit begins a new run and the current run end must be saved before processing the byte.

A fast way to process a byte is to simply code the sequence of operations required for that specific byte. For example, if CT is the current value of the run end counter, the byte whose binary value is `01111000` will cause the following actions to occur if the bit preceding it is a `1`:

1. Save the value of CT in the run end buffer

2. Add 1 to CT (for first white bit)

3. Save the value of CT in the run end buffer

4. Add 4 to CT (for four black bits)

5. Save the value of CT in the run end buffer

6. Add 3 to CT (for three whites bits)

If the preceding bit is a zero, step 1 is omitted since the initial white bit is a continuation of a run from the previous byte. After the byte is processed, the next byte is used to index the table for bytes preceded by a white bit. This gives the address of the routine to be used to process the next byte.

Since a separate routine is used for each bit pattern, it is advantageous to choose one bit pattern which is expected to occur infrequently and use it to flag the right edge of the line of image data being converted. The first byte beyond the edge can be temporarily reset to have that value, so that it is not necessary to test for the end of the line on any other path. If it is possible for the line to end in the middle of a byte, the bits beyond the edge of the image in that byte can be set to `1` and the flag can be placed in the following byte. If this procedure is used and the line ends on a byte boundary, it is convenient to set the byte following the edge to all `1`s and put the flag in the next byte. Thus when the right edge is reached it is guaranteed that a black run, some or all of whose bits are not part of the image, is being processed. The final entries in the run end buffer can then be set up as described in U.S. patent application Ser. No. 567,218. The preferred embodiment of the present invention uses the bit pattern `10101010` for the end-of-line flag. The block which processes this byte transfers control to the trellis routine (see FIG. 3) if the end of the line has not been reached; otherwise it causes a branch to the end-of-line processing.

As an example, suppose the image to be processed consisted only of bytes with one of the four binary values `00000111`, `11111100`, `01110000`, and `11111011`. Assume that no trimming or padding is required, that the image lines are required to begin and end on byte boundaries, and that the pattern `11111011` has been chosen as the end-of-line flag. FIG. 2 shows a routine which would convert one line of such an image to run ends. Since the first run end in the output buffer must describe a white run, conversion begins as if the bit preceding the first byte was a zero. The first byte of image data is accordingly used to index into Table I WTBL of addresses for bytes preceded by a zero bit, and control passes to the resulting address. If the byte begins with a black bit, a new run is starting, so CT is saved in the run end buffer; otherwise it is not. CT is then incremented and saved as appropriate for the byte being processed. After the byte is processed, control returns to one of the two table lookup procedures: to Table I (using WTBL) if the last bit in the processed byte is white, or to Table II (BTBL, the table of addresses for bytes preceded by a black bit) if the last bit in the processed byte is black. Whenever the `11111011` pattern is encountered, a test is performed to see if the end of the line has been reached. If it has, then the last run end is stored if necessary and processing terminates; otherwise the bit pattern is processed in the same manner as the other patterns.

To allow lines of image data to begin off of byte boundaries (as often happens when clipping is required), the bits of the first byte which are not to be used are reset to copies of the first bit to be used before the byte is processed. It is also necessary to reduce CT and the limiting value for CT in the inner loop by the number of bits discarded (so that the extra bits in the first byte do not show up in the run end vector) before entering the loop.

The advantage of the explicit coding procedure described above is that it executes quickly on an IBM Personal Computer. The disadvantage is that to handle all 256 possible values of a byte (particularly values which contain several runs) requires a great deal of code space. However, by examining a group of "typical" facsimile images it becomes apparent that some byte values occur much more frequently than others. The 60 byte values containing one, two, or three runs account for over 98% of all bytes processed in many images. This embodiment of the present invention therefore arranges to handle that subset of possible byte values very efficiently, and provides a slightly less efficient routine requiring less code space to handle most other byte values. The choice of how many and which byte values to handle using the faster procedure may be varied depending on the distribution of byte values in the images to be converted (e.g. halftoned images generally contain many more bytes having more than three runs than images of text or line art) and on the amount of code space available.

To process bytes which are not expected to occur frequently, a general routine is needed. The present method uses a "trellis" (see FIG. 3) which examines one bit at a time. There are many ways to test bits; a very efficient way on an IBM Personal Computer is to repeatedly shift the byte being examined left one bit and examine the carry flag after each shift. If the bit is the same as the previous bit, the process continues on to the next bit. If the bit is different, a branch occurs to a transitional state where CT is stored, and then the code to look for bits of the new color is branched to. After each bit is tested (and CT saved, if necessary), CT is incremented by one bit. The sequence of operations is shown in FIG. 3. Entry to this procedure occurs at one of the two points W0 or B0, depending on whether the last bit in the preceding image byte was white or black. If a state Wn is entered, the previous bit was white; similarly in a Bn state the previous bit was black. The W0 and B0 states test the first bit in the image byte (bit 0, numbering the image bits 0-7). In the Wn and Bn states for which n is 1, 2, 3, 4, 5, 6, or 7, CT is incremented by 1 for the previously tested bit and the nth bit is tested. If the tested bit is the same color as the previous bit, control passes to the next state of the same color, which increments CT and tests the next bit (if any). Otherwise a run end has been found and a transitional state is entered. The transitional states are those labeled "WBn" (white to black at bit n) and "BWn" (black to white at bit n). In these states CT is stored, and the state of the new color which will increment CT and test the next bit is entered. The W8 and B8 states increment CT for the eighth bit. After all of the bits have been tested, the next byte may be processed by using it to index into WTBL (if exit occurred from the white chain) or into BTBL (if exit occurred from the black chain).

In summary, each byte of image data is processed by using it to index into one of two lookup tables (depending on the value of the previous bit) to obtain the address of the code to be used to process the byte. This address may point to either a segment of code containing explicit instructions for handling that byte (used for bytes expected to occur frequently and for the end-of-line flag) or to one of the entry points of a routine which handles the bytes which are not expected to occur frequently. After each byte is processed, it is known (from the position in the code where processing stops) what color the last bit in the byte is, and hence which lookup table is to be used to process the next byte.

The following shows the flow of control in the inner block of the code which converts one line of image data to run end form. CT keeps track of the number of pels counted in the line so far; it is saved in the next available position in the run end buffer each time a run end is encountered. IMGPT points to the next byte of image data to be processed, and IX is a temporary variable used to index into the lookup tables WTBL and BTBL. Execution is initiated at the point labeled "LOOKUPW".

Those skilled in the art will recognize that there are several ways to make the code presented below execute more rapidly. For example, one could replicate the three lines of code at label "LOOKUPW" at each of the points where "goto LOOKUPW" is indicated, and similarly replicate the code at "LOOKUPB" at each point where a branch to that location is indicated. This would save one branch per byte processed through the table lookup procedures. One could also make use of the fast scanning instruction available on many processors to scan the fields of white and/or black bytes (calculating the value by which CT is to be incremented by multiplying the field length by 8).

The trellis routine of FIG. 3 may also be used in an alternate embodiment to convert 3 bytes (24 bits) of binary data to 10 bytes of grayscale, i.e. each 2.4 bits determines the value of one byte. The original bytes are put through a double chain similar to the trellis shown in FIG. 3. In this case, there is no CT saved when going from one chain to another. The output bytes byte 1, byte 2, . . . , byte 10 are set to zero before the chain is entered. The white chain tests bits and goes into the black chain at the appropriate place when a black bit is found. The black chain adds an appropriate value to one or two of the output bytes for each black bit, e.g.

There would be 24 stages in the chain (since 24 bits are being processed at a time). At the end, each output byte byte 1, byte 2, . . . , byte 10 could have at most the value 2.4*N, so the choice of N determines the range of output byte values. The entry point would not depend on the color value of the previous bit in this case.

Note that this trellis procedure for converting bits into grayscale could also be incorporated into an hybrid algorithm similar to the preferred embodiment of the present invention. Such an algorithm could incorporate features such as the skipping of all-white (zero) areas of the image and/or table lookup of some of the grayscale values.

Thus, while the invention has been described with reference to preferred embodiments thereof, it will be understood by those skilled in the art that various changes in form and details may be made without departing from the scope of the invention.