For the same data, Text part can get the correct result, but Raw part can't get the recognition result
H
Hedy Jiang
started a topic
about 2 years ago
For the same data, Text part can get the correct result, but Raw part can't get the recognition result.The specific reproduced projects are linked below：
Best Answer
G
Gwenaelle @MyScript
said
about 2 years ago
Hi Hedy,
Thank you for your update and sharing those information with us.
With "Raw Content" content type, the iink engine first performs an analyzing step to classify the ink content between Text and non-Text, (or when shape recognition is enabled between Text, Shape and non-Text). Then the corresponding recognition (text and/or shape) is applied on the different items according to their classification (Text and/or Shape).
This classification highly depends on the context: the more context, the more efficient and stable the algorithm is.
In your ink sample, you only have a character that takes the whole view size. So this is a limit case for the analyzer, for which it is less stable.
(for instance, there are not several characters allowing it to classify the ink as text, the shape and size of the ink are not text relevant for it, etc)
Therefore, it classifies your strokes as "non text", and then there is no text recognition performed.
I have a further question: in your application what kind of content are you trying to recognize?
If your content is only text, we highly recommend you using Text content part, as recognition performance will be better.
Also, I assume that the strokes coordinates in the data file are expressed in pixels, is that correct?
Best regards,
Gwenaëlle
H
Hedy Jiang
said
about 2 years ago
As you said, display non-text type, data is also pixels. One thing I'm curious about though is that if there's nothing wrong with my code, it shouldn't be a problem with the resolution. Because the data and test code are from the same device. The resolution of our device is xdip=ydpi=220
G
Gwenaelle @MyScript
said
about 2 years ago
Answer
Hi Hedy,
Thank you for your update and sharing those information with us.
With "Raw Content" content type, the iink engine first performs an analyzing step to classify the ink content between Text and non-Text, (or when shape recognition is enabled between Text, Shape and non-Text). Then the corresponding recognition (text and/or shape) is applied on the different items according to their classification (Text and/or Shape).
This classification highly depends on the context: the more context, the more efficient and stable the algorithm is.
In your ink sample, you only have a character that takes the whole view size. So this is a limit case for the analyzer, for which it is less stable.
(for instance, there are not several characters allowing it to classify the ink as text, the shape and size of the ink are not text relevant for it, etc)
Therefore, it classifies your strokes as "non text", and then there is no text recognition performed.
I have a further question: in your application what kind of content are you trying to recognize?
If your content is only text, we highly recommend you using Text content part, as recognition performance will be better.
Hedy Jiang
For the same data, Text part can get the correct result, but Raw part can't get the recognition result.The specific reproduced projects are linked below：
Hi Hedy,
Thank you for your update and sharing those information with us.
With "Raw Content" content type, the iink engine first performs an analyzing step to classify the ink content between Text and non-Text, (or when shape recognition is enabled between Text, Shape and non-Text). Then the corresponding recognition (text and/or shape) is applied on the different items according to their classification (Text and/or Shape).
This classification highly depends on the context: the more context, the more efficient and stable the algorithm is.
In your ink sample, you only have a character that takes the whole view size. So this is a limit case for the analyzer, for which it is less stable.
(for instance, there are not several characters allowing it to classify the ink as text, the shape and size of the ink are not text relevant for it, etc)
Therefore, it classifies your strokes as "non text", and then there is no text recognition performed.
I have a further question: in your application what kind of content are you trying to recognize?
If your content is only text, we highly recommend you using Text content part, as recognition performance will be better.
Best regards,
Gwenaëlle
- Oldest First
- Popular
- Newest First
Sorted by PopularHedy Jiang
Sorry, the link was not attached.The specific reproduced projects are linked below：
https://drive.google.com/file/d/1KfysfX-BCcBbdp6DkHCCzktzksRcnzU-/view?usp=share_link
Hedy Jiang
Sorry, The link above contains certificate information and the file has been completely removed.Here is the link to remove certificate related privacy：https://drive.google.com/file/d/184a6iPEPm8hzntVydCdBUjhtzW2JjKVq/view?usp=share_link
Gwenaelle @MyScript
Hi Hedy,
Thank you for your update.
When first testing, your project demo I have not been able to reproduce the issue, for both Text part and Raw Content I was getting the same results:
"label": "十",
"words": [ {
"label": "十",
"candidates": [ "十", "t", "+", "-1", "f" ], "label": "十",
After testing on another device, I have had different recognition result with the Raw Content being detected as non text :
"type": "Raw Content", "bounding-box": { "x": 3.35001326, "y": 11.0531626, "width": 7.43751669, "height": 10.881278 }, "elements": [ { "type": "Raw Content", "kind": "non-text", "id": "raw-content/4",Is that what you observe?
This is due to the fact that the device resolutions were different
On the first device , the resolution was xdpi=397, ydpi=395, while on the other xdpi= ydpi= 280
When it comes with batch off screen recognition, although you do not display the strokes, you need to provide proper dpi values to the renderer.
These correspond to the “resolution” of your input surface, where the ink was captured (not the ones on which you run the recognition)
In the same way, you should also take care to use a proper view size.
Those common pitfalls are described here:
https://developer.myscript.com/docs/interactive-ink/2.0/android/advanced/off-screen-usage/#common-pitfalls
Also, I assume that the strokes coordinates in the data file are expressed in pixels, is that correct?
Best regards,
Gwenaëlle
Hedy Jiang
As you said, display non-text type, data is also pixels. One thing I'm curious about though is that if there's nothing wrong with my code, it shouldn't be a problem with the resolution. Because the data and test code are from the same device. The resolution of our device is xdip=ydpi=220
Gwenaelle @MyScript
Hi Hedy,
Thank you for your update and sharing those information with us.
With "Raw Content" content type, the iink engine first performs an analyzing step to classify the ink content between Text and non-Text, (or when shape recognition is enabled between Text, Shape and non-Text). Then the corresponding recognition (text and/or shape) is applied on the different items according to their classification (Text and/or Shape).
This classification highly depends on the context: the more context, the more efficient and stable the algorithm is.
In your ink sample, you only have a character that takes the whole view size. So this is a limit case for the analyzer, for which it is less stable.
(for instance, there are not several characters allowing it to classify the ink as text, the shape and size of the ink are not text relevant for it, etc)
Therefore, it classifies your strokes as "non text", and then there is no text recognition performed.
I have a further question: in your application what kind of content are you trying to recognize?
If your content is only text, we highly recommend you using Text content part, as recognition performance will be better.
Best regards,
Gwenaëlle