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).
Comments
7 comments
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.
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?
yes, it should:)
c5750083-95cf-4930-a99b-00ddc9455f85
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!
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
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!
Please sign in to leave a comment.