Strange result with charConfidence

  • 1.6K Views
  • Last Post 25 January 2013
G Moore posted this 23 January 2013

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">
<charRecVariants>
<charRecVariant charConfidence="63" serifProbability="48">6</charRecVariant>
<charRecVariant charConfidence="25" serifProbability="44">5</charRecVariant>
</charRecVariants>5</charParams>

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).

Order By: Standard | Newest | Votes
Anastasia Galimova posted this 23 January 2013

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.

G Moore posted this 23 January 2013

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?

Anastasia Galimova posted this 23 January 2013

yes, it should:)

G Moore posted this 24 January 2013

c5750083-95cf-4930-a99b-00ddc9455f85

Anastasia Galimova posted this 24 January 2013

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!

G Moore posted this 24 January 2013

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

Anastasia Galimova posted this 25 January 2013

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!

Close