|Publication number||USRE38758 E1|
|Application number||US 09/884,759|
|Publication date||19 Jul 2005|
|Filing date||18 Jun 2001|
|Priority date||31 Jul 1990|
|Publication number||09884759, 884759, US RE38758 E1, US RE38758E1, US-E1-RE38758, USRE38758 E1, USRE38758E1|
|Inventors||Dan S. Bloomberg, David L. Hecht, Robert F. Tow, L. Prasadam Flores|
|Original Assignee||Xerox Corporation|
|Export Citation||BiBTeX, EndNote, RefMan|
|Patent Citations (24), Non-Patent Citations (1), Referenced by (30), Classifications (13), Legal Events (4)|
|External Links: USPTO, USPTO Assignment, Espacenet|
ThisThis application is a reissue of U.S. Pat. No. 6,076,738 issued Jun. 20, 2000 from application Ser. No. 08/240,798 filed May 10, 1994, which is a continuation of application Ser. No. 07/931,554, filed Aug. 18, 1992 AB which, in turn, was a continuation of application Ser. No. 07/560,514, filed Jul. 31, 1990 AB.
This invention relates to self-clocking codes for recording digital data on hardcopy recording media and, more particularly, to codes composed of glyphs that have digital data values encoded in their shapes. Advantageously, the glyphs are selected so that they tend not to degrade into each other, but the broader aspects of this invention are directed toward codes composed of discriminable glyphs, without specific limitation to the amount of image degradation and/or distortion the codes can tolerate.
Even more specifically, this invention relates to codes of the foregoing type that have a generally uniform textured appearance when they are printed or otherwise rendered in hardcopy form. The texture of higher spatial density codes is difficult for the casual observer to discern, so those codes commonly are described as having a generally uniform gray appearance.
Binary image processing and convolution filtering techniques for decoding self-clocking glyph shape codes are described herein, but those decoding processes are covered by concurrently filed and commonly assigned U.S. patent applications of Dan S. Bloomberg and Richard G. Stearns et al. Specifically, the Bloomberg application is on “Binary Image Processing for Decoding Self-Clocking Glyph Shape Codes,” and the Stearns et al. application is on “Convolution Filtering for Decoding Self-Clocking Glyph Shape Codes.” Furthermore, the adaptive scaling that may be utilized for scaling either or both of the above decoding processes to the decoding of a self-clocking glyph shape code of unknown spatial periodicity is covered by a concurrently filed and commonly assigned U.S. patent application of Bloomberg et al. on “Adaptive Scaling for Decoding Spatially Periodic Self-Clocking Glyph Shape Codes.”
Plain paper still is favored recording medium for storing and transferring human readable information, but the emergence of electronic documents processing systems has made it evident that the functional utility of plain paper and other types of hardcopy documents could be enhanced significantly if the human readable information they normally convey was supplemented by writing appropriate machine readable digital data on them. This machine readable data would enable the hardcopy document to actively interact with such a document processing system in a variety of different ways when the document is scanned into the system by an ordinary input scanner. See, for example, the copending and commonly assigned U.S. patent applications of Frank Zdybel, Jr. et al. and Walter A. L. Johhson et al., which were filed May 30, 1990 on “Hardcopy Lossless Data Storage and Communications for Electronic Document Processing Systems” (D/89190) and on “Form and System Utilizing Encoded Indications for Form Field Processing” (D/90003), respectively.
As a general rule, digital data is received by writing two dimensional marks on a recording medium in accordance with a pattern which encodes the data either by the presence or absence of marks at a sequence of spatial locations or by the presence or absence of mark related transitions at such locations. Ordinary magnetic and optical digital data recording conform to this style of encoding. Furthermore, the bar-like codes which have been proposed previously for recording digital data on paper also conform to the above-described encoding style. See U.S. Pat. No. 4,692,603 on “Optical Reader and Printed Bit-Encoded Data and Method of Reading Same,” U.S. Pat. No. 4,728,783 and U.S. Pat. No. 4,754,127 on “Method and Apparatus for Transforming Digitally Encoded Data into Printed Data Strips,” and U.S. Pat. No. 4,782,221 on “Printed Data Strip Including Bit-Encoded Information and Scanner Contrast.
Considered the aforementioned bar-like codes in some additional detail, it will be seen that their visual appearance is highly variable because it is data dependent so they tend to have a mottled appearance. This mottling is a readily discernible departure from the clean, crisp appearance of high quality printed documents, so it may be aesthetically objectionable to some observers. Furthermore, another drawback of these bar-like codes is the overhead that they contemplate. In particular, as taught by the above-identified patents, this overhead includes the registration marks which are provided for preserving the data clock, as well as the header information which is provided for describing the organization of the encoded data, such as the number of bits encoded along a given line of code.
It, therefore, will be evident that there is an urgent need for relatively efficient, visually improved codes for recording digital data on plain paper and of other types of hardcopy recording media, especially for applications in which such machine readable data is to be recorded in visual juxtaposition with human readable information. Furthermore, it will be appreciated that there is a need for efficient and reliable techniques for recovering digital data from such codes. Moreover, inasmuch as images carried by hardcopy documents often are replicated, such as by photocopying and by facsimile reproduction, it will be apparent that it would be very beneficial to have data encoding and decoding techniques that can tolerate a significant amount of image distortion.
In response to the foregoing and other needs, the present invention provides self-clocking glyph shape codes for encoding digital data in the shapes of glyphs that are suitable for printing on hardcopy recording media. Advantageously, the glyphs are selected so that they tend not to degrade into each other when they are degraded and/or distorted as a result, for example, of being photocopied, transmitted via facsimile, and/or scanned-in to an electronic document processing system. Moreover, for at least some applications, the glyphs desirably are composed of printed pixel patterns containing nearly the same number of ON pixels and nearly the same manner of OFF pixels, such that the code that is rendered by printing such glyphs on substantially uniformly spaced centers appears to have a generally uniform texture. In the case of codes printed at higher spatial densities, this texture is likely to be perceived as a generally uniform gray tone.
Still other features and advantages of this invention will become apparent when the following detailed description is read in conjunction with the attached drawings, in which:
While the invention is described in some detail hereinbelow with specific reference to certain embodiments, it is to be understood that there is no intent to limit it to those embodiments. On the contrary, the aim is to cover all alternatives, modifications, and equivalents falling within the spirit and scope of the invention as defined by the appended claims.
Turning now to the drawings, and at this point especially to
As will be understood, the user interface 27 collectively represents the input devices through which the user enters control instructions for the input scanner 25 and for the printer 26, as well as the image editing and manipulation instructions for the processor 22. Additionally, the interface 27 represents the output devices through which the user receives feedback with respect to the actions that are taken in response to the instructions that are entered by the user or otherwise, such as under program control. For example, the user interface 27 generally includes a keyboard or the like for entering user instructions, a monitor for giving the user a view of the process that is being performed by the processor 22, and a cursor controller for enabling the user to move a cursor for making selections from and/or fix entering data into a process that is being displayed by the monitor (none of these conventional components is shown).
The illustrated document processing system 21 is centralized, so it has been simplified by assuming that all control instructions and all image editing and manipulation instructions are executed by the processor 22 under program control. In practice, however, the execution of these instructions may be handled by several different processors, some or all of which may have their own main memory and even their own mass memory. Likewise, either or both of the input scanner 25 and the printer 26 may have its own user interface, as indicated by the dashed lines 28 and 29, respectively. Indeed, it will be evident that the document processing system 21 could be reconfigured to have a distributed architecture to operate with a remote input scanner and/or a remote printer (not shown). Data could be transferred from and to such remote scanner and printer terminals via dedicated communication links or switched communication networks (also not shown).
Customarily, the input scanner 25 is a bitmap scanner which scans the image of each hardcopy input document at a predetermined spatial resolutions of say, 300 s.p.i.×300 s.p.i. (spots/inch). In operation, the scanner 25 converts the individually resolved picture elements (commonly called “pixels” or “pels”) of the scanned image into corresponding digital values and assembles those digital values to produce a data structure (known as a “bitmap image”) which preserves the spatial relationship of the pixels to which the scanned-in values pertain. Although the following description focuses on applications in which the scanner 25 is a black-and-white scanner for converting the pixels of the scanned-in image into single bit digital values (i.e., “1” or “0”), it will be understood that it could be a gray-scale scanner for converting the pixels into maid-bit values. Furthermore, it will be evident that the scanner 25 could capture a bitmap image of a document or the like through the use of a video pick-up device and a so-called video “frame grabber”, together with appropriate thresholding logic if needed.
The printer 26, on the other hand, generally is a so-called bitmap printer for mapping the digital values of a bitmapped image file into the spatially corresponding pixels of the image it prints on a suitable recording medium, such as plain paper. The processor 22 may be configured to manipulate and store bitmapped image files and to transfer such files on demand to the printer 26. Alternatively, however, as shown in
To carry out this invention, there is a glyph encoder 33 for causing the printer 26 to print machine readable digital data glyphs on the recording medium, either alone or in juxtaposition with human readable information. For certain applications the glyph encoder 33 may be co-located with the processor 22 for inserting glyph encodings into the electronic document files prior to the translation of such flies into PDL descriptions. But, for other applications, it may be necessary or desirable to have the glyph encoder 33 insert the glyph encodings into the raster formatted bitmapped image file that is provided for the printer 26. PDL descriptions of glyph shape encoded data may take several different forms, including encapsulated bitmap representations of the code in which such data is encoded, font descriptions and layout locations for bitmap representations of the individual encoded glyph shapes (assuming that such bitmaps exist on or are down loadable to the front directory of the printer 26), and bit-by-bit descriptions of the bitmaps for the encoded glyph shapes.
More particularly, in accordance with the present invention as shown in
Glyph shape encoding clearly permits of many different implementations, some of which are suitable for the encoding of single bit digital values and others of which are suitable for the encoding of multi-bit values. For example, single bit values (“1” and “0”) conveniently are encoded by printing elongated, multi-pixel glyphs, each of which is composed of a predetermined number of adjacent “ON” (say, black) pixels which align along an axis that is inclined at an angle of about +45° or −45° from the transverse axis of the recording medium depending on whether the data value encoded therein is a “1” or a “0.” Such glyphs are examples of so-called “rotationally variant” glyphs because they can be mapped onto each other merely by rotational operations. They also are examples of glyphs which are readily discriminable, even in the presence of significant distortion and image degradation, because they do not tend to degrade into a common shape.
An important advantage of selecting the glyphs 36 so that they all have the same number of “ON” pixels is that the printed glyph code will have a generally uniform texture, which will take the form of a gray scale appearance when high density glyphs are viewed by a casual observer. It, therefore, is worth noting that this advantage may be realized by encoding the data in the rotation and/or the contour (collectively referred to herein as the “shape”) of the glyphs 36. For instance, single bit digital values may be encoded by rotationally invariant glyphs which have distinctly different contours, but the same number of “ON” pixels for the encoding of the “1's” and “0's”, respectively. See
While glyph shape encoding can be extended in theory to the encoding of digital values of any given bit length, n, simply by utilizing a code having 2n permissible glyph shapes, the code should be selected with care to ensure that its glyph shapes can be discriminated from each other reliably because such discrimination is essential for accurately recovering the data that is encoded therein.
Turning now to
In certain decoders, the image processing which is performed formed for decoding the glyph codes first locates the glyphs in the X-Y coordinates of the bitmap image space, then constructs a table for indexing the glyphs in the spatial order in which data was encoded in them, and then analyzes the glyphs in indexed order for sequentially extracting the data values that are encoded in them. In other decoders, the image processing classifies the glyphs by their shapes while concurrently locating their centers in the bitmap image space, so the decoded values of the glyphs conveniently are indexed to the bitmap image space. However, these spatially indexed decoded data values may be sorted in accordance with the spatial temple or pattern that governs their spatial ordering if it is desired to restore their serial order in the time domain.
In the decoding process illustrated by
As will be recalled, data typically is encoded into the glyphs in logical block-by-block, cell-by-cell order. For that reason, as indicated as 45, the X-Y coordinate labels for the glyphs typically are sorted in accordance with the spatial order of the data encoding, thereby constructing an index table for serially addressing the glyphs in the same order as the data was encoded into them. Or, if desired, a pointer (not shown) may be provided for randomly accessing the glyphs at one or more preselected locations within the bitmap image space, such that index is constructed at 45 for decoding selected ones of the glyphs in the order in which they are accessed. For example, a straightforward X-Y seek may be employed for relatively rapidly shifting such a pointer from the center of any one glyph to the center of any other glyph in the bitmap image space by computing the direction and the number of glyph centers in and by which, respectively the X and the Y coordinates of any two given glyph centers are displaced from each other in the bitmap image space. Given that directional information and those intermediate glyph center counts, an appropriate seek may be executed by first incrementally shifting the pointer from glyph center-to-glyph center in the indicated direction along, say, the X-axis, until the pointer has skipped across the given number of intermediate glyph centers, and by then repeating the above process to incrementally shift the pointer to tis intended destination along the other or Y-axis.
For recovering the encoded data values from the glyph code, 2n copies of the bitmap image of the code (where n is the bit length of the data value encoded in each of the glyph shapes) are each filtered, as at 51, by a filter that is matched to a respective one of the 2n permissible glyph shapes. For example, each of these images can be morphologically processed in accordance with a hit-miss filter that is weakly matched to a respective one (and only one) of the permissible glyph shapes. This yields 2n differently filtered versions of the bitmap image. Specifically, as a result of the hit-miss filtering, the pixel pattern proximate to any given glyph center or “data label” location in any given one of the filtered images is dependent upon the precision of the match between the hit-miss filter used to prepare the given image and the glyph residing at the given data label location (i.e., the closer the match, the greater the number of “ON” pixels proximate the e data label location). Therefore, the pixel patterns of the filtered images are compared, as at 52, data label location-by-data label location in logical encoding order (or random access order), to determine and sequentially read out, as at 53, the data values encoded in successive ones of the glyphs.
Prior to considering the decoding process in further detail, it may be helpful to briefly define some of the terms that have been adopted for describing “morphological image processing operations”:
“Morphological operation” is an operation on a bitmap image (called the “source image”) that uses a local rule at each pixel location with the source image to create another bitmap image (known as the “destination image). For convenience, the source and destination images sometimes are referred to as “pixelmap” images so that the operational rate can be viewed as operating on each “pixel”. “Bitmap” and “pixelmap” are synonymous terms for a data structure of a certain type, and “bit” and “pixel” are used interchangeably herein to describe the contents of such a data structure.
“Structuring Element (SE) is an image object, typically of relatively small size and simple shape, for probing the source image to extract information from it through the use of a selected morphological operations. The SE's referred to herein below are binary SE's. They are illustrated by using solid circles to identify their “ON” pixels and hollow circles to identify their “OFF” pixels. Their centers are identified by a video cross. SE's also may include “Don't Care” pixels, so it is noted that such pixels are represented by empty squares
The following terms are specific to binary morphological operations:
“EROSION” is an operation that is performed by probing a binary source image with a SE to write an “on” (1) or an “off” (0) pixel into the destination image for each pixel location within the source image, with the logic level of the pixel that is written at any given location depending upon whether the SE is matched or not by the source image when it is centered on the given pixel location. When the SE to be matched contains both “hits” and “misses,” the matching operation commonly is called a “hit-miss transform.” However, to simplify this disclosure, the definition of EROSION has been expanded to include such hit-miss transforms.
“DILATION” is an operation that is performed by probing a binary source image with a SE to write the SE into the destination image on centers corresponding to the locations of all “ON” pixels in the source image. As used herein, the DILATION is defined only for “hits” in the SE, so “misses” are ignored. Thus, the dilated destination image is the union of all replicas of the SE translated to all 1-pixels of the source image.
“OPENING” is an operation for replicating a SE in the destination image for each match to the SE in the source image. It is equivalent to an EROSION of a source image by an SE followed by a DILATION of the eroded image by the same SE. In keeping with the foregoing definitions of EROSION and DILATION, the definition of the OPENING operation has been expanded to include an EROSION with an SE containing both “hits” and “misses” followed by a DILATION with only the “hits” in the SE.
“CLOSING” is an operation composed of a DILATION or a source image followed by an EROSION of the dilated image. A CLOSING of an image is equivalent to a bit inversion of an OPENING that is performed on a bit inverted source image. In view of the foregoing definition of DILATION, it will be understood that a CLOSING is defined herein only for “hits” in the SE, so any “misses” are ignored.
Morphological operations are translationally invariant. In other words, a source image may be translated prior to be transformed, thereby causing the result to be translated or shifted by the same amount, without otherwise changing it. This means that these operations may be implemented with a high degree of parallelism because each bit or pixel in the source image is processed in accordance with the same rule.
EROSION, DILATION, OPENING and CLOSING operations performed with SE's consisting only of “hits” are geometrically “increasing” operations. Therefore, if a first image is contained in a second image, any of these operations that are performed with such a SE on the first image will also be contained in the second image. Furthermore, CLOSING is “extensive”, and OPENING “antiextensive”. Accordingly, the source image is contained in the destination image when the source is transmitted by a CLOSING, and the destination image is contained in the source image when the source is transformed by an OPENING. The results of OPENING and CLOSING operations are independent of the position of the center of the SE. Moreover, OPENING and CLOSING operations are indempotent, which means they will not change the transformed image if they are required to it.
Other terms that are sometimes used in describing morphological operations are:
A “hit-miss” SE is an SE that specifies a non-zero set of ON pixels and a non-zero set of OFF (“0”) pixels, with those two sets being non-overlapping (i.e., non-intersecting). A “weakly” matched filter specifies relatively few pixels of the pixel pattern to which it is matched, while a “strongly” matched filter specifies a large percentage of the pixel pattern to which it is matched.
A “hit-only” SE is an SE that specifies a non-zero set of ON pixels.
c. A Detailed Implementation
Referred now to
i. Clock Recovery
Once the system has been initialized to decode a given glyph code, a copy of the bitmap image of the code is loaded into main memory, as at 62, and this image then is transformed, as at 63, to provide an identically scaled bitmap image composed of at least one centrally located bit or “pixel,” but no more than a few, for each of the glyphs of the code. A described hereinbelow, the process for performing the transformation 63 typically is tailored to the spatial density at which the glyphs are printed because high density glyphs are more likely to be inseparably merged by the blurring that occurs during printing, copying and scanning than lower density glyphs. If the scanned-in glyphs are well separated, they may be shrunk to a single pixel near their respective centers. If, on the other hand, the scanned-in glyphs are touching, they may first be isolated from each other by filtering and then shrunk. For the moment it will be assumed that the transformation 63 transforms the scanned-in bitmap of the glyph code to a bitmap containing a single pixel at the approximate center of each data cell of the code, but it is to be understood that this is not essential.
ii. Determining Skew and Scale
In practice, the scanned-in image of the glyph code which is to be decoded may be skewed from the horizontal in a clockwise or counterclockwise direction, and may be distorted by scaling errors of different magnitude along its X-axis and/or its Y-axis. For that reason, provision is made at 65 for computing skew and scale correction factors to correct for such errors on a glyph-by-glyph basis (as shown) or on a data block-by-data block basis not shown or through the use of an image deskewing and rescaling process (also not shown).
As will be evident, skew and scale correction factors can be computed from the X-Y coordinates, in the scanned-in bitmap image space, of any three or more non-colinear reference points that have a nominal (i.e., error-free) spatial relationship which is known or capable of being determined. One of these reference points is selected to define a translationally invariant reference position, so that the skew and the scaling errors can be determined by comparing the distance and angle at which the actual and nominal positions of each of the other reference points are displaced from that spatially fixed reference position.
A previously pointed out, the data encoded glyphs typically are printed at a predetermined spatial density in generally square data arrays or blocks, so the centers of the glyph defining data cells (commonly referred to herein as the glyph centers) usually are arranged in a generally rectangular configuration. Therefore, the skew and scale correction factors suitably are computed from the X-Y bitmap image space coordinates of the apparent center pixels of at least three of the corner glyphs of the printed glyph code (although, it will be apparent from the foregoing description of the characteristics required of the so-called “reference points” that the apparent centers of any other uniquely identifiable glyphs could be employed in lieu of or in addition to the apparent centers of the corner glyphs). Thus, as illustrated, the X-Y coordinates of one after another of the selected corner pistels are identified at 66 and stored at 67, until it is determined at 68 that all of the information that is needed to compute the skew and scale correction factors at 65 has been collected.
Again, however, is to be understood that the apparatus centers of any other uniquely identifiable glyphs could be employed, in lieu of or in addition to the apparent centers of the corner glyphs, for computing such skew and scale correction factors, so reference is made to the foregoing description of the characteristics required of the so-called “reference points.” Moreover, it is to be understood that the center pixels of the corner glyphs may be used for computing the skew and scale correction factors for other types of glyph code patterns, such as hexagonal lattice patterns.
Relatively straightforward image analysis can be performed on the transformed bitmap that is provided by the transformation step 63 for identifying the X-Y coordinates of the corner pixels with sufficient precision to compute appropriate skew and scale correction factors. if the bitmap image of the apparent glyph center pixels is scanned in left-to-right and top-to-bottom order, starting slightly above the bitmap image, the first ON pixel that is encountered may be either the upper left-hand (UL) corner pixel or a pixel at or near the upper right-hand (UR) corner of the image. To resolve this ambiguity, the pixel is tentatively accepted as being the UL corner pixel, but it is subject to being deaccepted in favor of applying the UL corner pixel designation to any subsequently scanned pixel which is more than M pixels to the left and no more than N scan lines below the tentatively accepted pixel.
In some situations, the UL corner glyph may be missing, so the pixel representing the approximate center of the second glyph in the first line of the glyph code may be tentatively identified as being the UL corner pixel. If, however, N is chosen to be slightly greater (in scan lines) than the average center-to-center vertical spacing of the glyph or data cells, this error can be detected and corrected by imputing a UL corner pixel location to the bitmap image if an ON pixel is encountered anytime during the scanning of the N scan lines at a distance of roughly one data call to the left of the tentatively accepted pixel. In other situations, the pixel marking the appropriate center of the first glyph in the second row of data may be slightly to the left of the UL corner pixel. If, however, M is selected to be a suitably large fraction (say, about one-half) of the average horizontal center-to-center horizontal displacement (in printer pixels or pels) of the data cells, this anomaly generally will be ignored if the bitmap image is skewed by no more than 20° or so. In short, the preferred values for M and N depend on the data cell size in pels of the printed glyphs. For a 10 pel×10 pel data cell size, M suitably is selected to be about 5 pixels and N suitably is selected to be about 1.5 scan lines. By way of comparison, for a 5 pel×5 pel cell size, M typically is selected to be about 3 pixels and N typically is selected to be about 8 scan lines.
The above-described process for locating the UL corner of a scanned-in glyph code pattern is extensible by straight-forward analogy to provide corresponding processes for locating the apparent center pixels of the upper right-hand (UR) corner, the lower left-hand (LL) corner, and the lower right-hand (LR) corner glyphs of the scanned-in code pattern. The X-Y coordinates of these corner pixels can be identified in the bitmap image space by assigning (0,0) reference coordinates to, say, the pixel at the UL corner and by then referencing the coordinates of all of the other corner pixels to those reference coordinates.
Alternatively, the apparent center pixel of any or all of the corner glyphs can be found by performing one or more scans along a scan line that is sloped upwardly to the right for the UL and LR corner and upwardly to the left for the UR and LL. This scan line is initially positioned a safe distance outside the glyph code pattern, but it is incrementally shifted in toward the targeted corner glyph for each successive scan to progressively close in on it. Therefore, the apparent center pixel of the targeted corner glyph ordinarily is the first “ON” pixel that this scan process encounters.
Given the data cell size (in printer pels) of the printed glyphs and the X-Y bitmap image space coordinates of the apparent center pixels of the printed glyph code pattern, the rotation and scaling of the bitmap image of the given code can be determined as described above. Alternatively, the periodicity of the glyphs can be determined by performing a frequency transform, such as a Fourier transform or a Walsh transform, on either the scanned-in bitmap of the glyph code or on the bitmap of the glyph center pixels.
iii. Jump, Search, and Label
Thus, it will be evident that the average number of pixels between the centers of adjacent glyphs in the bitmap image of the glyph code also can be computed, as at 80. Given that information, a jump and search process can be initiated at, say, the UL corner pixel of the bitmap image of the apparent glyph centers to serially identify, as at 71, and store, as at 72, approximate X-Y bitmap image space coordinates for the apparent centers of one another of the spatially adjacent glyphs from one after another of the spatially adjacent rows of the printed glyph code. This coordinate labeling process starts with a jump from the UL corner pixel to the expected location of the center of the right-hand neighbor. If an ON pixel is found at that location, the pixel is labeled with its X-Y coordinates, and the process then jumps to the expected center location of the next neighboring glyph. If, one the other hand, the process fails to find an ON pixel at the expected center location, it carries out an expanding search, typically using an expanding diamond-like or spiral-like search pattern, to determine whether there is an ON pixel within a few pixel positions in one direction or another of the expected center location. If so, the process labels the first “ON” pixel it encounters with its X-Y coordinates, and then jumps to the likely center location of the next neighboring glyph. Conversely, if the search fails to find a nearby ON pixel, the process suitably returns to the locations at which it expected to find the center pixel for the glyph to label that location with its X-Y coordinates before jumping ahead to locate the center pixel of the next glyph. This process continues glyph-by-glyph and row-by-row of the scanned-in glyph code to provide a X-Y coordinate label in the bitmap image space for each and every glyph center location.
iv. Recalibrated Glyph Center Labeling (Optional)
As shown in
v. Restoring Encoded Data Values to the Time Domain
After the X-Y coordinate labels have been applied to the glyph center pixels and all necessary calibrations of them have been completed, the X-Y coordinate labels ordinarily are sorted into a logical block sequence, thereby serially re-ordering them in accordance with the order in which data is encoded into the glyphs labeled by them. Moreover, as indicated at 85, incrementally increasing index values are assigned to the re-ordered labels so that they can be retrieved easily in sorted sequence.
vi. Determining Data Values from Glyph Shapes
To provide the filtered bitmap images, the bitmap image of the glyph code advantageously is morphologically ERODED, through the use of independent operations, in accordance with a plurality of different weak hit-miss filters, each of which is relatively well matched to a different one of the permissible glyph shapes and relatively poorly matched to all the others. These filters are referred to as “weak” hit-miss filters because they only loosely specify the shapes of the glyphs (i.e., the patterns of “ON” and “OFF” pixels that define the glyph shapes). Consequently, the filtering of a matching glyph within the source image typically causes several ON pixels to be written into the target or filtered image near the center of the matching glyph, while the filtering of a non-matching glyph results in significantly fewer, if any, ON pixels being written into the targeted image near the center of the non-matching glyph In other words, the filtering causes a significantly larger number of ON pixels to be written into a filtered image for the glyphs that are well matched by the filter that is used to produce that particular image than for the glyphs that are unmatched or only poorly matched by that filter.
After it is determined at 105 that all of the filtered bitmap images have been constructed, a glyph index pointer 107 is set, as at 106, to the index value for the first glyph that is to be decoded, thereby retrieving the X-Y image space coordinate label for the first glyph from memory. This label is used at 111 for spatially addressing one after another of the filtered bitmap images at approximately the center of the glyph that is to be decoded, so that the ON pixels that each of those images contains proximate the center of that particular glyph can be counted as at 112. These counts, in turn, are stored in separate cells of a data array, as at 113.
Typically, the pixel counting is performed by starting at the labeled center point of the addressed glyph and by then moving outwardly from there to count the number of ON pixels falling within a selected number of progressively larger squares centered on the glyph center point. This “square ring” search pattern expands in all directions at a rate of one pixel positioning, but the search is confined to the data cell for the glyph that is being decoded. For example, as shown in
Upon confirming at 115 (
vii. Systems Utilizing Error Correction Encoding
As shown in
vii. Transforms for Isolating Glyph Center Pixels
Returning to the problem of identifying the centers of the glyphs in a glyph shape code, three different techniques will be described for performing that function. Two methods for transforming the scanned-in bitmap image of the glyph code into a bitmap of the glyph center pixels, as at 63 in
Turning first to the large filter implementations of the transformation 63, it will be understood that the glyphs of lower density glyph codes (i.e., these that are printed with densities of up to about 2500 glyphs/in2 using glyph cells as small as 6 pels×6 pels) usually are reasonably well separated in the scanned-in bitmap image of the glyph code. Therefore, as shown in
As shown in
The bit-ANDing 163 of the image OPENING operations 161 and 162 may create some unintended holes at glyph center locations in the resulting bitmap image, but these holes can be filled. To that end, this particular version of the transformation process 63 (
Upon the completion of the fill and repair process, the bitmap image may have several ON pixels proximate at least some glyph locations. However, the image can be thinned to approximately one pixel per glyph by performing a iterative thinning process on it until thinning stops. As shown in
After each iteration of the thinning process, as determined at 198, the thinned bitmap image is bit-compared at 199 with the bitmap image 190. If the images are identical, thinning has stopped, so the process is completed. Otherwise, the thinned image is copied at 190, and the process is then repeated in an attempt to further thin the image.
Even higher density glyph codes having spatial conditions up to say, 5625 glyphs/in2 with glyph cells as, say, small as 4 pels×4 pels may be transformed to locate the apparent centers of their glyphs using essentially the same process in described above for the transformation of the medium density codes. However, the transformation of those higher density codes generally requires several iterations of the fill and repair process 171-176 (FIG. 20).
Alternatively, as pointed out above, the transformation process 43 (
Accordingly, a thinning process of the above-described type (see
The thinning of the filtered bitmap (
Turning now to
As shown in
More particularly, for decoding a glyph code in accordance with the process shown in
The glyph code is decoded glyph-by-glyph, starting at 213 approximately at the center of, say, the UL corner glyph (suitable processes already have been described for locating that center). To perform the decoding, the bitmap image is convolved at 212 with each of the n glyph matching filters. This produces n gray-scale images, each of which represents the convolved response of this glyph code image to a filter that is relatively strongly matched to a respective one of the n permissible glyph shapes. A local search is conducted at 214 in each of these convolved images, from the approximate or estimated location of the glyph that is being decoded, to label the maximum convolution values the respective images contain for that particular glyph with their X-Y image space coordinates, as at 215. As shown in
The indexed convolution values (i. e., local maxima or sums) for the n convolved images are sorted in rank order by value at 216, and the two highest values then are compared at 217. If the values are unequal, as determined at 221, the data value for the glyph that is being processed is decoded by reference to the convolution producing the greater value and the X-Y label for that convolution value is assigned to the decoded data value for indexing it in the bitmap image space. See 222. On the other hand, if it is determined at 221 that the two largest convolution values are equal, the X-Y label for a selected one of them is recorded to identify an error location and an error count is incremented, as at 223. Thereafter, as indicated at 224, an estimated decoded data value is produced by reference to the convolution producing the selected convolution value, and the X-Y label or index for the selected convolution value is assigned to the decoded data value for indexing it in the bitmap image space.
The foregoing process is repeated to decode the next glyph if it is determined at 218 that there is another glyph to be decoded. Whenever there is another glyph to be decoded, the decoding process employs the bitmap image space X-Y coordinates (i. e., index location) of a previously decoded neighboring glyph for advancing to the next glyph through the use of the above-described jump and search routine.
In view of the foregoing, it will now be understood that the present invention provides self-clocking glyph shape codes, including codes that have a pleasing printing appearances and substantial tolerance to image degradation and distortion. It also will be apparent that such codes can be regenerated as desired. Furthermore, it will be evident that such codes can be decoded using a variety of different decoding techniques, including decoding processes that adaptively scale themselves for the decoding of spatially periodic codes of different spatial periodicities.
|Cited Patent||Filing date||Publication date||Applicant||Title|
|US3257545 *||21 Jul 1959||21 Jun 1966||Nederlanden Staat||Method of recording marks and method and device for scanning these marks|
|US3654435 *||2 Jun 1970||4 Apr 1972||Columbia Controls Research Cor||Magnetically readable bar and code|
|US3898434 *||11 Feb 1974||5 Aug 1975||Control Point Inc||Machine readable coded member|
|US3978319 *||29 Oct 1975||31 Aug 1976||International Business Machines Corporation||Universal self-clocking code reading method and apparatus|
|US4115806 *||23 May 1975||19 Sep 1978||Bausch & Lomb Incorporated||Image analysis data transfer|
|US4286146 *||12 Jan 1979||25 Aug 1981||Hitachi, Ltd.||Coded label and code reader for the coded label|
|US4610025 *||22 Jun 1984||2 Sep 1986||Champollion Incorporated||Cryptographic analysis system|
|US4630308 *||20 Jul 1984||16 Dec 1986||Fuji Electric Corporate Research & Development Ltd.||Character reader|
|US4728783 *||1 May 1987||1 Mar 1988||Cauzin Systems, Incorporated||Method and apparatus for transforming digitally encoded data into printed data strips|
|US4754127 *||8 May 1987||28 Jun 1988||Cauzin Systems, Incorporated||Method and apparatus for transforming digitally encoded data into printed data strips|
|US4817171 *||9 Apr 1985||28 Mar 1989||British Telecommunications Public Limited Company||Pattern recognition system|
|US4905296 *||18 Mar 1988||27 Feb 1990||Schlumberger Systems & Services, Inc.||System for shape recognition|
|US4924078 *||25 Nov 1987||8 May 1990||Sant Anselmo Carl||Identification symbol, system and method|
|US4980923 *||2 Feb 1989||25 Dec 1990||Seiko Instruments Inc.||Dilation/erosion conversion circuit|
|US5073954 *||28 Feb 1989||17 Dec 1991||Electrocom Automation, Inc.||Bar code location and recognition processing system|
|US5091966 *||31 Jul 1990||25 Feb 1992||Xerox Corporation||Adaptive scaling for decoding spatially periodic self-clocking glyph shape codes|
|US5128525 *||31 Jul 1990||7 Jul 1992||Xerox Corporation||Convolution filtering for decoding self-clocking glyph shape codes|
|US5168147 *||31 Jul 1990||1 Dec 1992||Xerox Corporation||Binary image processing for decoding self-clocking glyph shape codes|
|US5221833 *||27 Dec 1991||22 Jun 1993||Xerox Corporation||Methods and means for reducing bit error rates in reading self-clocking glyph codes|
|US5315098 *||27 Dec 1990||24 May 1994||Xerox Corporation||Methods and means for embedding machine readable digital data in halftone images|
|US6179207 *||18 Jun 1996||30 Jan 2001||International Business Machines Corporation||Method for writing single width bar codes on semiconductors wafers|
|GB2179008A *||Title not available|
|JPS62140554A *||Title not available|
|WO1986000445A1 *||19 Jun 1985||16 Jan 1986||Champollion Inc||Cryptographic analysis system|
|1||*||M. Mansour, IBM Technical Disclosure Bulletin, vol. 26, No. 2, pp. 766-767, Jul. 1983.|
|Citing Patent||Filing date||Publication date||Applicant||Title|
|US7493250||18 Dec 2000||17 Feb 2009||Xerox Corporation||System and method for distributing multilingual documents|
|US7505041||16 Feb 2007||17 Mar 2009||Microsoft Corporation||Iteratively solving constraints in a font-hinting language|
|US7586628 *||20 Jun 2003||8 Sep 2009||Infoprint Solutions Company, Llc||Method and system for rendering Unicode complex text data in a printer|
|US7925495||11 Feb 2009||12 Apr 2011||Xerox Corporation||System and method for distributing multilingual documents|
|US7962172||24 Feb 2010||14 Jun 2011||Silverbrook Research Pty Ltd||Print onto a print medium taking into account the orientation of previously printed content|
|US7991153||26 Aug 2008||2 Aug 2011||Nanoglyph, LLC||Glyph encryption system and related methods|
|US7999964||16 Aug 2011||Silverbrook Research Pty Ltd||Printing on pre-tagged media|
|US8009321||30 Mar 2010||30 Aug 2011||Silverbrook Research Pty Ltd||Determine movement of a print medium relative to a mobile device|
|US8027055||27 Sep 2011||Silverbrook Research Pty Ltd||Mobile phone with retractable stylus|
|US8057032||19 May 2010||15 Nov 2011||Silverbrook Research Pty Ltd||Mobile printing system|
|US8118395||29 Dec 2009||21 Feb 2012||Silverbrook Research Pty Ltd||Mobile device with a printhead and a capper actuated by contact with the media to be printed|
|US8259360 *||26 Mar 2009||4 Sep 2012||Heidelberger Druckmaschinen Aktiengesellschaft||Method and apparatus for correcting geometric errors while preserving defined information|
|US8262000||29 Apr 2010||11 Sep 2012||Sd-X Interactive||Method and system for encoding and decoding data|
|US8303199||20 Dec 2010||6 Nov 2012||Silverbrook Research Pty Ltd||Mobile device with dual optical sensing pathways|
|US8363262||29 Jan 2013||Silverbrook Research Pty Ltd||Print medium having linear data track and contiguously tiled position-coding tags|
|US8640018 *||22 Jan 2007||28 Jan 2014||Xerox Corporation||User interface tag for use in processing a document|
|US8640019 *||2 Sep 2009||28 Jan 2014||Xerox Corporation||User interface tag for use in processing a service on a scannable document|
|US20020077805 *||18 Dec 2000||20 Jun 2002||Hecht David L.||System and method for distributing multilingual documents|
|US20040257591 *||20 Jun 2003||23 Dec 2004||International Business Machines Corporation||Method and system for rendering Unicode complex text data in a printer|
|US20050184991 *||26 Jan 2004||25 Aug 2005||Beat Stamm||Dynamically determining directions of freedom for control points used to represent graphical objects|
|US20050200913 *||11 Mar 2004||15 Sep 2005||International Business Machines Corporation||Systems and methods for identifying complex text in a presentation data stream|
|US20060250481 *||9 May 2005||9 Nov 2006||Silverbrook Research Pty Ltd||Print medium with self-clocking data track and method of printing onto the print medium|
|US20070116358 *||22 Jan 2007||24 May 2007||Klotz Leigh L Jr||User interface tag for use in processing a document|
|US20080165193 *||10 Nov 2006||10 Jul 2008||Microsoft Corporation||Iteratively solving constraints in a font-hinting language|
|US20090171653 *||11 Feb 2009||2 Jul 2009||Xerox Corporation||System and method for distributing multilingual documents|
|US20090244591 *||26 Mar 2009||1 Oct 2009||Heidelberger Drickmaschinen Ag||Method and Apparatus for Correcting Geometric Errors While Preserving Defined Information|
|US20090262569 *||17 Oct 2008||22 Oct 2009||Naoharu Shinozaki||Semiconductor memory device with stacked memory cell structure|
|US20090323126 *||2 Sep 2009||31 Dec 2009||Xerox Corporation||User Interface Tag For Use In Processing A Service On A Scannable Document|
|US20100190525 *||24 Feb 2010||29 Jul 2010||Silverbrook Research Pty Ltd||Print onto a print medium taking into account the orientation of previously printed content|
|WO2011137066A1 *||25 Apr 2011||3 Nov 2011||Sd-X Interactive, Inc.||Method and system for encoding and decoding data|
|U.S. Classification||235/494, 382/203, 382/181, 235/456|
|International Classification||G06K7/016, G06K9/18, G06K19/06|
|Cooperative Classification||G06K7/143, G06K7/0166, G06K19/06037|
|European Classification||G06K7/14A2K, G06K19/06C3, G06K7/016D|
|30 Jul 2002||AS||Assignment|
Owner name: BANK ONE, NA, AS ADMINISTRATIVE AGENT, ILLINOIS
Free format text: SECURITY AGREEMENT;ASSIGNOR:XEROX CORPORATION;REEL/FRAME:013111/0001
Effective date: 20020621
Owner name: BANK ONE, NA, AS ADMINISTRATIVE AGENT,ILLINOIS
Free format text: SECURITY AGREEMENT;ASSIGNOR:XEROX CORPORATION;REEL/FRAME:013111/0001
Effective date: 20020621
Effective date: 20020621
|31 Oct 2003||AS||Assignment|
Owner name: JPMORGAN CHASE BANK, AS COLLATERAL AGENT, TEXAS
Free format text: SECURITY AGREEMENT;ASSIGNOR:XEROX CORPORATION;REEL/FRAME:015134/0476
Effective date: 20030625
Owner name: JPMORGAN CHASE BANK, AS COLLATERAL AGENT,TEXAS
Free format text: SECURITY AGREEMENT;ASSIGNOR:XEROX CORPORATION;REEL/FRAME:015134/0476
Effective date: 20030625
|11 Oct 2007||FPAY||Fee payment|
Year of fee payment: 8
|18 Oct 2011||FPAY||Fee payment|
Year of fee payment: 12