Community

• 

  Slowdima

  • July 22, 2013 10:45

  Hello Yury,
  
  The described functionality cannot be implemented. Pre-recognition is always called with settings specified in layout properties. At least, according to documentation.
  
  Assume that you specified an empty pre-recognition area in layout properties. Then image objects detection process will be very fast. Document analysis module will find and recognize barcodes, detect separators and pictures, find all text-like objects ( text highlighted in green ), but text will not be OCRed ( there will be no blue text objects ). On such page you will not be able to find a statict text or character string or currency. But it is stuill possible to use white gaps., barcodes, separators, object collections and regions. In some scenarios this is enough for finding correct block regions. For some other scenarios you can use white gaps, barcodes, separators etc. to find an area of interest and then call RecognizeText to get OCR results for this area only. This would significantly speed up matching process in comparison with case of pre-recognition for the whole page. This is the purpose of RecognizeText functions family.
  
  In your case a correct approach is performing some tests to find the most suitable pre-recognition settings and using them in all the cases.
  

  No 0 Yes
• 

  ybag

  • July 22, 2013 12:26

  Thanks, Slowdima,
  but does it mean that RecognizeText always OCRs the image hence it's equivalent to "Balanced" ot "Thorough" recognition Mode (which one exactly, if so)?
  And what about printer type in RecognizeText()-which one does it use?
  And can you say smth about combination of settings like "Dot-matrix"+"Typographic" - is it always equivalent to one of them (I notices some effect of that kind,
  like, say, Typographic+Dot-Matrix equivalent to simple "Typographic") or can be considered like a new "printer type"? Maybe you know how printer type combination algorithm works?
  Thanks, Yury

  No 0 Yes
• 

  Slowdima

  • July 23, 2013 11:52

  Hello Yury,
  
  I just meant that settings of RecognizeText function are always equal to currently specified settings in layout properties. For example, if current language is English, current recognition mode is Balanced and current text type is Typographic , then these settings will be used, not German + Fast + Typewriter . When you change corresponding settings in layout properties, you also change them for RecognizeText.
  
  Regarding text types. The point is that character glyphs printed in typographuc way differ from those obtained on matrix printer or typewriter. So, when you enable one or another text type, you just enable corresponding set of character etalons used for recognition. If some of documents are printed in typographic way and some others are filled by matrix printer, then you just need to enable both text types. This can lead to a bit worse results for each certain document ( since recognizer has larger number of hypotheses for each printed character ), but at the same time you will get adequate results for 2 different text types. If you would enable only typographic, then the results for typographich documents would be a bit better, but much worse for documents printed on dot matrix printer. This is how it works.
  

  No 0 Yes
• 

  ybag

  • July 23, 2013 21:01

  Thanks, Dima, for explanation, I think it's a drawback to "hardcode" current prerecognition settings inside this function, hope this would change in the future..
  About combination algorithm: is this kind of text types merge also used for FC printer type selection? when you adjust recognition parameters for some field
  in FC-you can also specify one or many text types-the combination of text types there works the same way (extension of character glyphs' "alphabet")?
  
  

  No 0 Yes
• 

  Slowdima

  • July 24, 2013 11:04

  Hello Yury,
  
  Basically, recognition settings in field properties work in similar way. But, sets of character etalons are only a part of that functionality. There are also algorithms for lines detection, words detection, detection of certain text type from all alowed and so on and so on. In addition, settings in field properties provide you with larger possibilities. For example, it is possible to recognize magnetic inks there or hand printed text. For full-text recognition detection of these text types is computationally expensive, but we can recognize them in frames of certain field. However, if you allow a lot of text tyoes in advanced recognition settings, you will see that the result is really awful. 2-3 text types can be reaasonable for a field, but not more.

  No 0 Yes
• 

  ybag

  • July 24, 2013 12:50

  Hello, Dima,
  "but we can recognize them in frames of certain field"-that means if we recognize just a small field, not full text, specifying many text types would be fast? But still not good?
  Or "certain field" could mean that each character should be in some frame or box?
  In practice, what text types to choose, you decide by experiments?
  
  What I do in my work to maximize recognition %-I generate seveal (4-12) hypotheses of each field , recognize them each with different text type setting and then I have a script that
  checks each hypothesis with strict rules, then with slightly less strict rules , and so on and chooses first that matches. Rules could be some CRC check (in INN eg) or existence of
  "^" symbol or existence of uncertain symbols or data type match , etc. For this task would it be enough to use only one printer type per hypothesis or not? Text type detection is made for the whole field, for each line or word or character?
  
  Can I ask you also if you could explain in short what "single line" ("odnostrochnoe") checkmark in recognition settings affect?
  And "Single word" also interesting - I got answer from Abbyy support that one of its effects is that it adds spaces in recognition results before dictionary checking.
  
  Thanks a lot
  

  No 0 Yes
• 

  Slowdima

  • July 26, 2013 11:24

  Hello Yury,
  
  On FlexiLayout level we cannot understan ICR or magnetic inks, because detection of specific text type from all image objects ineeds for severely hard nathematics. But for text field on FlexiCapture level we can explicitly specify that it has certain text type or certain markup ( like letters-in-frames ). From mathematical point of view this is completely different situation from detection of specific text type anywhere on a page. This is the reason why FlexiCapture can recognize hand-printed text if we captured its region correctly and specified the corresponding recognition settings in field properties. But in FlexiLayout corresponding text will be recognized as occasional rubbish.
  
  Your idea is having several fields with the same region but with different recognition settings for them. This idea is corrrect. I faced similar approach numerous times for fixed forms, which can be filled both by hands or typed on PC. We of course can specify for a field that it may have 2 text types: OCR and ICR, and for each certain document program would detect automatically which case is current one. But the results will be worse than in case of 2 fields with only one allowed text type in each. From the other side, with this approach you need to create a joint field whhich will be populated by script based on the best recognized variant. So, this approach is rather complicated and can be recommended only if automatic text type detection within one field provides you with unsatisfactory results
  

  No 0 Yes
• 

  Slowdima

  • July 26, 2013 11:32

  Options "one line" and "one word" mean exactly what you might think looking at their names. Option "one line" explicitly says that field has only one line of text. This option can be very helpfyul for ICR text, if automatic lines detection works incorrectly. Option "one word" in simplest case just removes all spaces from recognition result. But more important is that it can be very helpful for data types based on dictionaries or regular expressions. In this case you tell the program that whole field content should be checked against dictionary, not some part ( without this option words are detected automatically based on interword spaces )

  No 0 Yes

Please sign in to leave a comment.