AmitGorvadiya / tesseract-ocr

Automatically exported from code.google.com/p/tesseract-ocr
Other
0 stars 0 forks source link

different output looping on the same bitmap #233

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
Steps that reproduce the problem:
1. Read a bitmap (from file)
2. TessBaseAPI::InitWithLanguage(NULL, NULL, "eng", NULL, false, 0, NULL);
3. loop TessBaseAPI::TesseractRect with input the bitmap and print the
recognized string
4. TessBaseAPI::End();

I expected the same string as output, of course, but there are cases for
which I obtain different strings. With various experiments I noticed that
sometimes the output string is the same but not the confidence (computed
with TessBaseAPI::TextConf)

I'm using tesseract 2.04 with Linux (aim: reading text extracted from images)

I attach below two bitmaps where the problem occours (values 0-255). In the
first I obtain different output strings with a 2 iterations (read as NNCH
UNION and UNCH UNION) while for the second example I need 4 iterations to
evidence the problem (read WIUJAMSON for 3 times and WILLIAMSON the 4th). 
Some different strings or confidence values are obtained if I include
InitWithLanguage and End in the body of the loop but again not the same output.

Original issue reported on code.google.com by carlamar...@gmail.com on 18 Aug 2009 at 8:34

Attachments:

GoogleCodeExporter commented 9 years ago
The textline finder in tesseract uses random numbers as part of a least median 
of
squares fitting algorithm. This produces different results, especially on short 
text
lines such as yours. This is a known issue that will be fixed in a future 
release.

Original comment by theraysm...@gmail.com on 20 Aug 2009 at 4:30

GoogleCodeExporter commented 9 years ago
Hi Ray,

I have the same issue and wanted to add that in my case, the 1st scan is 
absolutely
perfect but the 2nd scan is not only different, it totally misses out for the 
bottom
half of the text area. See attached image:
- first scan finds "Toll Free: 877.887.1818" and "www.serenitymovers.com"
- 2nd scan finds: "Toll Free: 877.887.1818" and "WWW.SIIIi1Zy|11OV\S.COT\"

So it seems that the usage of the random variable makes it go from perfect to 
very
poor ... hope this helps. I m using Tesseract version 2.03 by the way.

Original comment by patrick....@gmail.com on 26 Aug 2009 at 1:37

Attachments:

GoogleCodeExporter commented 9 years ago
Fixed in 3.01

Original comment by theraysm...@gmail.com on 20 May 2010 at 6:31

GoogleCodeExporter commented 9 years ago
3.02 gives different output for the same input.

Original comment by ydf...@gmail.com on 14 Jul 2015 at 1:11