---
title: "Release Notes: v1.1.0 (2026-08-09)"
product: "LumiScan Area Detector"
component: "lumiscan-area-detector"
version: "1.2.0"
display_version: "1.2.0.6"
latest_version: true
language: "en"
url: "https://docs.hdvisionsystems.com/en/lumiscan-area-detector/1.2.0/release-notes/v1-1-0-2026-08-09.html"
---

# Release Notes: v1.1.0 (2026-08-09) – LumiScan Area Detector

First functioning release of LumiScan Area Detector. Earlier versions registered the application’s Data Layer nodes but returned a fixed placeholder result, so nothing below was usable before.

## New

**Area detection.** `<module>/detect-area/execute` finds the regions in a camera image and reports each one’s area and position, along with the total area across them all. No reference picture is needed: you describe what counts as a region by how bright, how large and how round it is.

**Five ways of finding a region**, chosen by `input/method`. `CIRCLE` sweeps a range of intensity levels and keeps what looks like a blob at several of them, which holds up when the lighting does not; the other four threshold once and take every connected region, whatever its shape. All five report a measured pixel area.

**A choice of threshold when measuring**, `input/method-specific/corrected/min-level`. A local threshold follows uneven lighting and suits fine features; a global one takes a solid region whole, which is what measuring a solid part needs.

**Shape filters** - area, circularity, convexity and elongation - so only the regions of interest are reported, with the meaning of each explained on the node itself.

**Optional preprocessing** before detection: Laplacian of Gaussian, Difference of Gaussians or Determinant of Hessian.

**A region of interest per run**, `input/crop`, to restrict and speed up the search.

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

**The regions' shapes, when you ask for them.** `input/publish` adds outlines, simplified polygons and masks beside the measurements, each on its own Data Layer node. Empty by default, and then a run costs exactly what it did before. The whole-frame and per-region masks are ordinary image nodes, so another application reads one with the code it already has for a camera image. (Withdrawn in 1.2.0: a single label image replaced all of them.)

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

## Worth knowing

Every invalid input is reported at once, and each message names the **node** to change rather than an internal field name - `threshold/min (250) must not exceed threshold/max (220)`.

An empty result means no regions matched, and nothing else: every other reason a run could produce nothing is caught before detection and reported as a negative status code.

The shapes are deliberately not inside the result flatbuffer. Over the REST API a flatbuffer arrives as one JSON string with its numbers quoted, so an array of coordinates comes back as an array of strings - too slow to use. The result carries the per-region point counts that slice the published buffers instead.

When measuring solid parts, turn `input/method-specific/corrected/min-level` off. A local threshold compares a pixel against its surroundings, so the middle of a large solid region - where the surroundings are equally bright - drops out and the region is measured hollow. See [Analysing a Scene](https://docs.hdvisionsystems.com/en/lumiscan-area-detector/1.2.0/lumiscan-area-detector/analysing-a-scene.html).