I'm getting a strange OCR result with the Cloud SDK. Consider the following XML output:

<charParams l="1503" t="529" r="1535" b="593" wordStart="0" wordFromDictionary="0" wordNormal="0" wordNumeric="1" wordIdentifier="0" charConfidence="100" serifProbability="44" wordPenalty="0" meanStrokeWidth="63">
<charRecVariant charConfidence="63" serifProbability="48">6</charRecVariant>
<charRecVariant charConfidence="25" serifProbability="44">5</charRecVariant>

As you can see, there are two rec variants, '5' and '6'. The '6' has a significantly higher confidence. However, the rec variant that ends up being chosen is '5'. Why is this, and how can it be avoided?

(The correct rec variant is indeed 6 in this case).

asked 23 Jan '13, 01:16

G%20Moore's gravatar image

G Moore

Dear G Moore, the choice between the recognition variants depends not only on the charConfidense, but also on the context.

For example if the word with the “e” hypothesis is not a dictionary word while the word with the “c” hypothesis is a dictionary word, the latter will be selected as the recognition result even if its confidence is little less. In your case, a possible reason may be that in some writing styles "5" is placed lower than the other digits, and maybe in your text the recognized character is placed low. If you are interest in the exact cause of this behavior, please provide your image.

If you need to select the characters from the recognition variants according to charConfidence only, we recommend to export the recognition result to XML and then implement it on your side.

This answer is marked "community wiki".

answered 23 Jan '13, 21:21

Anastasia%20Galimova's gravatar image

Anastasia Ga... ♦♦

Yes I expected the context does come into play where words are involved, however in a string of numeric characters there is no context as such. Additionally, the text is uniform with no height differences so I can't imagine there's any other reason why the choice was made as it was. Would it help for me to give you the task id to take a look?

(23 Jan '13, 21:27) G Moore

yes, it should:)

(23 Jan '13, 23:01) Anastasia Ga... ♦♦


(24 Jan '13, 02:17) G Moore

Thank you! I will discuss this issue with our developers, and now I can recommend to use the default profile instead of the textExtraction one, as the issue is not reproduced in this case. Sorry for the inconvenience!

(24 Jan '13, 15:32) Anastasia Ga... ♦♦

We prefer to use textExtraction, but we implemented additional processing on our end to take char confidence into account for strings of digits, so it's okay for now. Will check back here for any updates

(24 Jan '13, 21:37) G Moore

Our developers confirmed that it was a bug in our technologies: removing geometrical distortions, that is enabled via textExtraction profile, worked wrong. It is already fixed in the current version of our technologies, which will be implemented in Cloud OCR SDK this spring. Thank you for your patience!

(25 Jan '13, 20:08) Anastasia Ga... ♦♦
showing 5 of 6 show 1 more comments
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here



Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported



Asked: 23 Jan '13, 01:16

Seen: 1,614 times

Last updated: 25 Jan '13, 20:08

© 2016 ABBYY. All rights Reserved. www.ABBYY.com | Privacy Policy | Legal