iink SDK on Device

For the same data, Text part can get the correct result, but Raw part can't get the recognition result

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:


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

Sorry, The link above contains certificate information and the file has been completely removed.Here is the link to remove certificate related privacyhttps://drive.google.com/file/d/184a6iPEPm8hzntVydCdBUjhtzW2JjKVq/view?usp=share_link

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



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

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



Login or Signup to post a comment