Feature Center:
Introductory Statement
Robert Thibadeau
Robotics Institute
School of Computer Science
Carnegie Mellon University
The practical application of pattern recognition often reveals new avenues of knowledge about it. We have designed a system called "Feature Center" to represent a "practiced view" of the pattern recognition domain of automated document conversion. Our laboratory with close corporate and government support since 1983 has had ample real-world experience in diverse areas of automated document conversion as optical character recognition, oil-well log conversion, printed wiring board conversion, mechanical drawing conversion, electrical wiring drawing conversion, architectural drawing conversion, diagram and graph drawing conversion, chinese character recognition, and handwritten character conversion. A characteristic that appears to be universal to every real-world system we have encountered is what we call "clumping." A system may prove cost effective in automated conversion for one clump of documents but fail utterly on another clump.
This coarse deficiency is not a property of a swing from one type of document to another but appears to be a property of a much more subtle, and less controllable, shifting of the context in which the document clumps originate. One executive's office has a different optical character recognition requirement from another and his needs change, one month he wants newspaper articles read and another he wants sales books read. Accepted drawing practices are different year to year, manufacturing site to manufacturing site, design firm to design firm. This is not the exception but the rule. We attribute this to a fundamentally obvious property of documentation -- that it represents an abstract schematic where it is the common knowledge among the human viewers that provides the basis for interpretation. People always seek to minimize the content on paper without sacrificing the communication. This means that, inevitably and with few exceptions, a clump occurs because there is a natural clumping of common knowledge among people in practice. Even the exceptions, such as drawings that represent tooling such as printed wiring board artwork or mylar templates, there are subtle clumps that are just as damaging to automated conversion -- in annotation, metrological assumptions, shape interpretation, and revisioning policies. We know of many instances, for example, where printed wiring tooling is assumed, by the workers in the printed wiring board shop, to have defects that they will manually fix during manufacture. The tooling is not, actually, authorative. Of course, the situation is even worse in the case of mechanical drawings that do not represent the tooling itself.
Feature Center was designed to integrate over a decade of specific system experience into a framework for easily customizing any particular system to the next "clump" of documents encountered. It is not a replacement for tailored systems for broad areas of application (e.g., printed wiring board conversion versus office document conversion), but is, rather, designed to provide a single metholodology that can be applied in all application contexts. It is not a replacement for writing code -- it sacrifices generality for simplicity and transparency. Other systems exist for customizing pattern recognition by knowledgeable code writers. Our hope was to define a tool that any personal computer user would find fun to use by non-technical people while significantly expanding the scope of application of the conversion package. Feature Center is, in this sense, one of a family of "applications kernels" that have broad applicability to diverse software applications in the area of automated document conversion (e.g., the ACIS kernel, ref). The scenario: "when the fully automated conversion fails, go to feature center to fix the problem." This keeps things simple for the user: he tries to have it work automatically and if it fails (viz., does not meet his expectation), he can fix the problem. Failures always occur even in systems, such as Adobe's Green Giant or Caere's Pagekeeper that will hide failures with the general solution of retaining the image segment when automated interpretation fails. Our practical background says there will still be the need to convert that image segment on occasion and then the need will be compelling.
Another universal observation that we have made is that the person who is operating (responsible for, etc.) the pattern recognition system usually has some ideas about why the pattern recognition failed. He develops a naive understanding of the pattern recognition system's problems quite readily. We have observed patterns in these naive understandings and have incorporated these observed patterns of naive problem solving into the understanding required to operate feature center effectively.
The reason that we find Feature Center interesting from the point of view of pattern recognition is that it requires us to put a rigorous framework on naive views of document conversion. This mapping helps us to view pattern reocognition in a different light -- showing areas where, perhaps, new research is "naturally" invited and can be understood for its importance in practical application.
2. Definition of Feature
3 User Interaction Model
4 Overview of the Eleven Feature Classes
5 Underlying Implementation
6 Results and Conclusions