IOS应用源码之【应用】用OCR技术识别验证码-tesseract.rar

©ACM, 2009. This is the authors’ version of the work. It is posted here by permission of ACM for your personal use. Not for

redistribution. The definitive version was published in Proceedings of the International Workshop on Multilingual OCR 2009, Barcelona,

Spain July 25, 2009. http://doi.acm.org/10/1145/1577802.1577804.

Adapting the Tesseract Open Source OCR Engine for

Multilingual OCR

Ray Smith Daria Antonova Dar-Shyang Lee

Google Inc., 1600 Amphitheatre Pkwy, Mountain View, CA 94043, USA.

Abstract

We describe efforts to adapt the Tesseract open source OCR

character classifier beyond changing a few limits. The Tesseract

classifier has adapted easily to Simplified Chinese. Test results on

English, a mixture of European languages, and Russian, taken

from a random sample of books, show a reasonably consistent

word error rate between 3.72% and 5.78%, and Simplified

Chinese has a character error rate of only 3.77%.

Keywords

Tesseract, Multi-Lingual OCR.

1. Introduction

Research interest in Latin-based OCR faded away more than a

script, which has several thousand more of its own, as well as

using Han characters. The number of characters is one or two

orders of magnitude greater than Latin. Arabic is mostly written

with connected characters, and its characters change shape

according to the position in a word. Hindi combines a small

number of alphabetic letters into thousands of shapes that

represent syllables. As the letters combine, they form ligatures

whose shape only vaguely resembles the original letters. Hindi

then combines the problems of CJK and Arabic, by joining all the

symbols in a word with a line called the shiro-reka.

much easier to develop a classifier for a small number of classes,

one approach has been to recognize the radicals [1, 2, 5] and infer

the actual characters from the combination of radicals. This

approach is easier for Hangul than for Han or Hindi, since the

radicals don't change shape much in Hangul characters, whereas

in Han, the radicals often are squashed to fit in the character and

mostly touch other radicals. Hindi takes this a step further by

changing the shape of the consonants when they form a conjunct

consonant ligature. Another example of a more language-specific

work-around for Arabic, where it is difficult to determine the

languages as possible [7], so we are also interested in adapting the

Tesseract Open Source OCR Engine [8, 9] to many languages.

This paper discusses our efforts so far in fully internationalizing

Tesseract, and the surprising ease with which some of it has been

possible. Our approach is use language generic methods, to

minimize the manual effort to cover many languages.

2. Review Of Tesseract For Latin

Fig. 1 is a block diagram of the basic components of Tesseract.

The new page layout analysis for Tesseract [10] was designed

from the beginning to be language-independent, but the rest of the

in the direction of connected component (CC) analysis and

operating on outlines of the components. The first step after CC

Input: Binary Image

Component Outlines

In Text Regions

Character

Outlines

In Text Regions

Character

Outlines

Organized

Find Text

Lines and

Words

Blob Finding

Input: Binary Image

Component Outlines

In Text Regions

Character

Outlines

In Text Regions

Character

Outlines

Organized

©ACM, 2009. This is the authors’ version of the work. It is posted here by permission of ACM for your personal use. Not for

redistribution. The definitive version was published in Proceedings of the International Workshop on Multilingual OCR 2009, Barcelona,

Spain July 25, 2009. http://doi.acm.org/10/1145/1577802.1577804.

problem is detecting inverse text inside a box vs. the holes inside

a character. For English, there are very few characters (maybe ©

and ®) that have more than 2 levels of outline, and it is very rare

to have more than 2 holes, so any blob that breaks these rules is

"clearly" a box containing inverse characters, or even the inside or

outside of a frame around black-on-white characters.

After deciding which outlines make up blobs, the text line finder

[11] detects (horizontal only) text lines by virtue of the vertical

overlap of adjacent characters on a text line. For English the

overlap and baseline are so well behaved that they can be used to

uncertain spaces are decided.

Fig.2 is a block diagram of the word recognizer. In most cases, a

blob corresponds to a character, so the word recognizer first

classifies each blob, and presents the results to a dictionary search

to find a word in the combinations of classifier choices for each

blob in the word. If the word result is not good enough, the next

step is to chop poorly recognized characters, where this improves

the classifier confidence. After the chopping possibilities are

exhausted, a best-first search of the resulting segmentation graph

puts back together chopped character fragments, or parts of

sensible arrangement of punctuation around it. For the English

version, most of these punctuation rules were hard-coded.

The words in an image are processed twice. On the first pass,

successful words, being those that are in a dictionary and are not

dangerously ambiguous, are passed to an adaptive classifier for

training. As soon as the adaptive classifier has sufficient samples,

it can provide classification results, even on the first pass. On the

second pass, words that were not good enough on pass 1 are

From the foregoing description, there are clearly problems with

this design for non-Latin languages, and some of the more

changed the character code to a UTF-8 string, as that was the most

flexible, but that turned out to yield problems with the dictionary

representation (see section 5), so we ended up using an index into

a table of UTF-8 strings as the internal class code.

©ACM, 2009. This is the authors’ version of the work. It is posted here by permission of ACM for your personal use. Not for

redistribution. The definitive version was published in Proceedings of the International Workshop on Multilingual OCR 2009, Barcelona,

Spain July 25, 2009. http://doi.acm.org/10/1145/1577802.1577804.

where some assumption is made over

characters being arranged on a

horizontal text line. Fortunately,

Tesseract operates on outlines of CCs

in a signed integer coordinate space,

which makes rotations by multiples of

discarded. (An exception has to be made for dotted/dashed

leaders, as typically found in a table of contents.) Otherwise, a

bounding box that contains both the small CC and its larger

neighbor is constructed and used in place of the bounding box of

the small CC in the following projection.

A "horizontal" projection profile is constructed, parallel to the

estimated skewed horizontal, from the bounding boxes of the CCs

using the modified boxes for small CCs. A dynamic programming

algorithm then chooses the best set of segmentation points in the

projection profile. The cost function is the sum of profile entries

appropriate body characters.

Once the cut lines have been determined, whole connected

components are placed in the text-line that they vertically overlap

the most, (still using the modified boxes) except where a

component strongly overlaps multiple lines. Such CCs are

presumed to be either characters from multiple lines that touch,

and so need cutting at the cut line, or drop-caps, in which case

they are placed in the top overlapped line. This algorithm works

well, even for Arabic.

After text lines are extracted, the blobs on a line are organized

that Chinese symbols are composed of multiple glyphs (radicals),

it would be difficult to get the correct character segmentation

without the help of recognition. Considering the limited amount

of information that is available at this early stage of processing,

the solution is to break up the blob sequence at punctuations,

which can be detected quite reliably based on their size and

spacing to the next blob. Although this does not completely