Release Notes: v1.1.0

Shape based object detection. <module>/find-object/execute searches a camera image for a known object and reports every occurrence, each with its position, the size of the template that matched, a score and the name of the object. Matching is on gradient orientations rather than pixel intensities, so it tolerates lighting changes and surface texture that defeat intensity correlation.

An object is one picture, stored as <object-dir>/<object-id>.png, where the file name is the object id. The detector does not rotate or rescale it, so a part that has to be recognised at several orientations is several objects - screw-m6-front, screw-m6-tilted - searched for in turn. See Object Storage.

One object per search. <module>/find-object/input/object-id names the object and is required; an empty value is refused with status code -2. There is no "search everything" run: a detector is built around one picture, so searching several objects would mean several detectors, and the detector processes the whole image once each time - the expensive part. Running the method once per object keeps that cost visible.

Teaching from the live camera. system/create-object/execute crops a region out of a camera image and saves it as <object-id>.png, so an object can be taught in the real lighting at the real working distance without transferring files. Saving over an existing id replaces it, and output/object-path reports where the file landed.

Several modules, each with its own find-object, settings and results, so one installation can watch several cameras at once. One license is valid for ten modules.

One object directory for the application, system/object-dir, with the objects in it listed on system/objects - one entry per .png, which is also the complete list of templates. system/set-object-dir changes it and saves the choice.

A speed setting that works. input/preprocess/bin-size searches at a lower resolution: both the image and the object’s picture are downsampled by that integer factor before matching, so the cost falls with the pixel count. On a full HD image with a 128x128 object, 2 measured about six times faster at an unchanged score and 4 about fourteen times faster. It buys that with precision - positions quantise to bin-size pixels - and with detail, since an object binned far enough loses the edges the detector keys on and is refused, which is reported as a failed run rather than as an absent part. Positions are always reported in the pixels of the image you configured. input/pyramid reads like a speed setting and is not one: deeper pyramids measured slightly slower.

A region of interest per run, input/crop, and a choice of whether positions are reported in image or crop coordinates.

A status on every operation: output/status-code and output/status-text, where a negative code always means the run failed and produced nothing.

The searched region is searched exactly as configured - the detector needs a particular size and pads up to it rather than dropping part of your region. Positions stay exact, so a match reported at y=300 is at y=300 in the image you configured.

An empty result means the object was not in the image, and nothing else. Every other reason a search could come back empty - the object’s picture is missing, the image is unusable, a pyramid level is invalid, the picture has too little contrast for the detector to key on, bin-size left too little of it to key on - is caught before the search runs and reported as a negative status code. See Execution Status.

Invalid inputs are all reported together, each naming the offending input and the value it holds.

Objects and the object directory are always interpreted relative to the application’s configuration directory. Absolute paths, and paths leading outside it, are refused.