Data Layer Reference
Every address below is relative to
hdvisionsystems/lumiscan-object-finder/
Data Layer
LumiScan Object Finder offers its functions on the Data Layer under hdvisionsystems/lumiscan-object-finder.
On ctrlX OS (ctrlX CORE or ctrlX IPC), LumiScan Object Finder uses the ctrlX Data Layer.
On a PC with Windows 11 or Ubuntu 24.04, LumiScan Object Finder uses LumiScan Keryx.
The node addresses, types and call patterns are the same on both. LumiScan Object Finder offers:
-
a stream subscription to one source (experimental)
How addresses are built, how to call functions, the status codes and the tools are described in LumiScan Keryx.
Application-wide nodes
| Address | Type | Access | Description |
|---|---|---|---|
|
string[] |
read |
The modules that exist right now |
|
string |
read |
Directory object pictures are read from, relative to the configuration directory |
|
string[] |
read |
Objects that can be searched for, one per |
|
method |
write |
Switch to another object directory |
|
string |
read/write |
Directory to switch to |
|
method |
write |
Save a crop of a live image as an object |
|
string |
read/write |
Image to cut from |
|
string |
read/write |
The object’s name; also the file name. Overwrites an existing one |
|
int32 |
read/write |
Left edge of the region to cut |
|
int32 |
read/write |
Top edge |
|
int32 |
read/write |
Width, must be > 0 |
|
int32 |
read/write |
Height, must be > 0 |
|
string |
read |
File written by the last run |
|
method |
write |
Add a module |
|
string |
read/write |
Name for the new module |
|
method |
write |
Remove a module |
|
string |
read/write |
Module to remove |
|
method |
write |
Persist the module list |
|
method |
write |
Persist one module’s settings |
|
string |
read/write |
Module to save |
|
string |
read |
What the node a module subscribes to must hold, as a JSON Schema (draft-04) of its JSON form: here a |
Every method also serves output/status-code and output/status-text. On ctrlX OS, one licence
covers ten modules, see Module Management.
Per-module nodes
All addresses below are under <module-id>/find-object/.
| Address | Type | Access | Default | Description |
|---|---|---|---|---|
|
method |
write |
- |
Run one detection |
|
string |
read/write |
(empty) |
Address of the image node to search |
|
string |
read/write |
(empty) |
Object to look for. Required - an empty value is refused |
|
float64 |
read/write |
0.6 |
Smallest acceptable score, 0 to 1 |
|
float64 |
read/write |
0.0 |
Minimum pixel distance between two matches |
|
uint8[] |
read/write |
[1,2] |
Image pyramid levels to search at. Not a speed setting |
|
string |
read/write |
IMAGE |
|
|
uint16 |
read/write |
0 |
Left edge of the region to search |
|
uint16 |
read/write |
0 |
Top edge |
|
uint16 |
read/write |
0 |
Width; 0 reaches the right edge |
|
uint16 |
read/write |
0 |
Height; 0 reaches the bottom edge |
|
int32 |
read/write |
1 |
Search at 1/N resolution: faster, less precise. 1 disables it |
|
float64 |
read/write |
0.0 |
Gaussian blur in X; 0 or less disables it |
|
float64 |
read/write |
0.0 |
Gaussian blur in Y; 0 means same as X |
|
uint32 |
read/write |
0 |
Blur kernel in X; 0 computes it, else odd |
|
uint32 |
read/write |
0 |
Blur kernel in Y; 0 computes it, else odd |
|
flatbuffers |
read |
empty |
Matches of the last run |
|
int16 |
read |
0 |
Outcome as a number |
|
string |
read |
(empty) |
Outcome in words |
Per-module image stream nodes (experimental)
All addresses below are under <module-id>/, beside find-object/. The stream searches each frame
with the inputs of find-object, all but input/input-image-address. See
Finding Objects on an Image Stream.
| Address | Type | Access | Default | Description |
|---|---|---|---|---|
|
bool |
read/write |
as applied |
Stream mode: |
|
string |
read/write |
as applied |
The one source, a camera’s stream folder, e.g. |
|
string |
read/write |
as applied |
The tag on the module’s results: the module’s step in the lineage of each stream result carries it. Empty: the module id, e.g. |
|
uint32 |
read/write |
as applied |
Frames that may wait while one is searched, 1-64 |
|
bool |
read/write |
as applied |
|
|
method |
write |
- |
Check the inputs of |
|
method |
write |
- |
Drop the source named by |
|
string |
read/write |
(empty) |
The source to drop, as |
|
as the inputs |
read |
|
What |
|
string |
read |
- |
Hash of what the results are made with, 16 hex digits |
|
bool |
read |
false |
|
|
flatbuffers |
read |
empty |
One |
|
string |
read |
(empty) |
Why the last frame that could not be searched failed, naming the source by its address |
|
uint64 |
read |
0 |
Milliseconds since the stream started |
|
uint64 |
read |
0 |
Frames the subscription delivered |
|
uint64 |
read |
0 |
Frames searched, each with a result |
|
uint64 |
read |
0 |
Frames pushed out of the queue, or waiting when the source was replaced or dropped |
|
uint64 |
read |
0 |
Frames that could not be searched |
|
uint64 |
read |
0 |
Frames lost before they arrived |
|
uint64 |
read |
0 |
Search time of all searched frames, summed, microseconds |
The inputs of control/subscribe start with what is applied, and only control/subscribe/execute
applies them. control/subscribe/execute is refused for stream mode without an address or a queue size
outside 1-64, control/unsubscribe/execute for an address that is not the source (Rejected, ctrlX:
DL_INVALID_VALUE). When <module-id>.json cannot be written, both answer CreationFailed (ctrlX:
DL_CREATION_FAILED) and change nothing. The stream nodes are the same in every consumer, see
Streams.
The result flatbuffer
output/result carries hdv.object_find.Result:
| Field | Type | Meaning |
|---|---|---|
|
Match[] |
All matches, sorted by score descending |
|
int |
Top left corner of the matched template, in pixels |
|
int |
Size of the template that matched |
|
float |
0.0 to 1.0 similarity |
|
string |
The object that was found; the same on every match of one run |
|
ulong |
Index of the best match; 0 when there are none |
|
float |
Score of the best match; 0.0 when there are none |
|
string |
Object of the best match; empty when there are none |
|
uint |
The frame the coordinates are in |
|
float |
The threshold that was applied |
|
ulong |
Microseconds since epoch, when the run completed |
control/subscribe/output/stream/result carries hdv.stream.StreamObjectMatches
(stream_object_matches, registered as
types/hdvisionsystems/lumiscan-object-finder/stream_object_matches): lineage, where the frame came
from, and result, the hdv.object_find.Result above.
Configuration file
The application settings file lumiscan-object-finder.json is in the configuration directory:
| Platform | File |
|---|---|
ctrlX OS |
|
PC (Windows) |
|
{
"system": { "logLevel": "INFO" },
"object-dir": "templates",
"modules": [ { "id": "module-1", "advanced": false } ]
}
logLevel accepts TRACE, DEBUG, INFO, WARN, ERROR, FATAL and OFF, and is read at
startup. Each module’s saved settings are in <module-id>.json beside it, and so are its image
stream’s mode, source, queue size and keep-latest-output, under stream.
Starting from an Example (PC)
On a PC, the Object Finder writes an example of its settings into a folder of your choice, and ends without starting. For example, on Windows:
lumiscan-obj-find --generate-settings C:\work\object-finder-settings
Without a folder (-g alone) it writes into the current folder. The example is the application settings
file lumiscan-object-finder.json, which names the module module-1, and the module file
module-1.json beside it: every input of find-object with the value it has by default, except the
image address, which is the Cam Driver’s camera1.
Beside them, in schemas/, are the schemas the two files name in "$schema": lumiscan-object-finder.schema.json,
lumiscan-object-finder-module.schema.json, and stream.schema.json for the stream section of a module file. They
describe every key the Object Finder reads - each input of find-object with its type, its default and the
range a run accepts - so an editor that understands JSON Schema can check the files and show what each
value means. Copy the schemas folder along with the files: system/save-module-inputs keeps the
"$schema" of a module file it saves.
Existing files are never overwritten: when one of them is in the folder already, nothing is written and the
Object Finder says which.
The Object Finder then names the folder it reads its settings from - on Windows by default
C:\ProgramData\HD Vision Systems GmbH\LumiScan Vision Suite\lumiscan-obj-find\etc\lumiscan-object-finder.
Edit the example, copy it there, and start the Object Finder. See also
Where the files are (Windows).