Requirements
Licence
The application requires the licence SWL-W-XCx-TEXTxxRDSxHDVSx-V1NN. One licence covers ten
modules; the eleventh acquires a second licence of the same key. Without any licence the
application shuts down shortly after starting; the reason is written to the system log.
An image source on the same ctrlX CORE
The application reads its images from another application’s Data Layer image node. That application must run on the same ctrlX CORE - remote Data Layer access is not supported.
In practice this is LumiScan Cam Driver, but any application works as long as its image node provides these four children:
| Node | Type | Description |
|---|---|---|
|
array of uint8 |
Raw, uncompressed pixel data |
|
uint64 |
Image width in pixels |
|
uint64 |
Image height in pixels |
|
string |
GenICam pixel format name |
Language models
The application ships with English (eng) and the orientation model (osd) installed, which is
enough to read Latin-script text out of the box.
Other languages need their Tesseract .traineddata file placed in a directory the application can
read - the removable-media interface means a USB stick works - and
system/set-tessdata-dir pointed at it. See
Language Models.
Image quality
OCR is more demanding of the image than code reading is, and no setting recovers text the camera did not capture. As a rule of thumb:
-
characters at least 20 pixels tall, and 30 or more for small or noisy print;
-
good contrast between the marking and its background;
-
the text in focus, and not glared out by the lighting;
-
the text roughly upright, unless you enable an orientation-detecting layout.
Dot-matrix and laser-etched marking are harder than printed text. If engine = DEFAULT struggles
with them, LEGACY is worth trying before anything else.
Storage
The application stores nothing but its module list and their settings - a few kilobytes of JSON in the application’s configuration directory, which is part of the active solution. The language models are installed with the application and are not written to.
Timing
Reading is synchronous: the call to execute returns when the read has finished.
How long that takes is driven mostly by how much image the engine is given, which makes
input/crop the setting to reach for first when a cycle is too slow - a tight crop around the label
is both faster and more accurate than the whole frame. The AUTO_OSD and SPARSE_OSD layouts cost
noticeably more than the others, because they load a second model and work out the orientation
before reading.
See Reading Accurately.