ROI image source binding: fix inspection region errors

An inspection region can look correct on screen yet belong to a different image than the processing step receives. Some editors reject the drawing operation; others accept coordinates that later select the wrong pixels. This problem often appears after copying a processing group, changing an acquisition source, or adding a crop or rotation operation.

Start with ROI image source binding, not camera replacement or threshold adjustments. You need to establish which image the tool processes, which image the editor displays, and how their coordinates relate. The checks below separate reference errors from display scaling, stale frames, and configuration persistence problems.

Match the symptom to the likely cause

An ROI is more than a rectangle on a preview. It is geometry interpreted in an image coordinate system. Depending on the software, the region may also carry a reference to an image object or processing context.

The displayed picture and the inspection input do not always need to be identical buffers. A scaled preview can work correctly when the editor maps coordinates back to the processing image. Problems arise when that mapping is missing, incorrect, or associated with another source.

Treat this table as a test order, not a diagnosis by itself. Several faults can produce the same visible displacement.

Verify the inspection input before editing the region

Begin with the most probable explanation: the viewer and the inspection step reference different outputs. A viewer may still show the acquisition image while the tool receives a cropped, converted, or previously captured image.

1. Pause acquisition and processing where practical. Use a recorded image or a controlled bench setup so the evidence does not change between checks.
2. Select the inspection step that owns the ROI. Read its configured image input rather than inferring the source from the visible preview.
3. Trace that input upstream. Record the acquisition source, processing branch, and any intermediate output that supplies the image.
4. Select that same output in the editor or viewer. Use the software's documented source-selection mechanism.
5. Draw a small region around an unmistakable feature. Choose an asymmetric corner, hole, or printed mark rather than a large uniform surface.
6. Run only the necessary processing steps. Confirm that the inspection overlay appears over the feature in the image actually processed.

Record useful metadata alongside the test: source identifier, image width and height, pixel format, crop origin, frame identifier, and acquisition timestamp when available. Matching dimensions alone do not prove matching sources.

A well-designed image display and ROI interface keeps the display source, inspection source, and editing context explicit. If the editor supports several views, label them by processing output rather than using ambiguous names such as “current image.”

Check coordinate transforms when the source is correct

If the inspection input and displayed source are correct, inspect the coordinate path next. Cropping, resizing, rotation, and viewer zoom each affect where a region appears, but they do not all change the underlying image coordinates.

Distinguish these operations:

• Viewer zoom: changes presentation without necessarily changing the image supplied to processing.
• Image resizing: creates an image with a different pixel grid.
• Image cropping: changes the image origin and usually its dimensions.
• Image rotation: changes the coordinate relationship and may change output dimensions.

The separate guide to camera-side ROI cropping explains acquisition cropping. A crop performed inside a processing group is a different stage, even when both operations produce the same image dimensions.

Worked example: a resized crop

Suppose a source image is 1920 × 1200 pixels. Processing extracts a crop whose top-left corner is at source coordinate (320, 200). That crop is 800 × 600 pixels, but the viewer displays it at 400 × 300 pixels.

Assume the image axes run rightward and downward, with no rotation or reflection. Let the displayed image begin at viewer coordinate (40, 30), accounting for margins around the picture.

Here, both scale factors equal 400 / 800 = 300 / 600 = 0.5. A viewer click at (140, 90) therefore maps as follows:

• Processing x = (140 − 40) / 0.5 = 200 pixels.
• Processing y = (90 − 30) / 0.5 = 120 pixels.
• Source x = 200 + 320 = 520 pixels.
• Source y = 120 + 200 = 320 pixels.

A displayed rectangle measuring 50 × 30 pixels spans 100 × 60 processing pixels. If the tool consumes the cropped image, use the processing coordinates. If it consumes the original image, include the crop origin.

These equations describe a simple axis-aligned mapping, not every editor's API convention. Some interfaces already return image coordinates, so applying this conversion again would introduce another error. Confirm whether coordinates refer to pixel centers or boundaries, and check endpoint conventions before converting a rectangle into array indices.

For rotation, use the actual transformation applied to the image rather than adding a crop offset alone. The guide to camera image rotation explains why display orientation and processing orientation need separate consideration.

Separate frame mismatch from source mismatch

Two images can come from the same camera and still represent different moments. A preview might show the newest frame while an inspection queue processes an older one. The ROI then appears displaced relative to a moving part even though its coordinate mapping is correct.

First repeat the test with one saved image. If the problem disappears, inspect acquisition timing and buffer ownership before altering the region geometry.

For a simple timing example, assume a part travels at 250 mm/s and the preview leads processing by 40 ms. The expected position difference is:

That displacement is a timing effect, not a calibration error. Increasing the ROI may hide it temporarily while admitting unwanted background.

Associate displayed frames, processed frames, and overlays using available frame metadata. The article on matching asynchronous inspection outputs to frames covers this association in more detail.

Also check whether the acquisition library reuses image memory. A reference to a live buffer may not preserve its contents after the next acquisition. Use the library's documented ownership, retention, or copy mechanism whenever the application needs a stable image for editing.

Repair copied groups and stale image references

A copied processing group may retain a reference to its original source, depending on how the application stores connections. Another possibility is that the group's external image input is correct while an internal tool remains connected to a different output.

Use the smallest repair that restores an understandable data path:

1. Inspect the group boundary. Identify the external image input and the internal step that receives it.
2. Check the internal inspection tool. Confirm that its input comes from the intended group input or documented intermediate image.
3. Rebind through the supported interface. Choose the intended image output explicitly, then reopen the ROI editor.
4. Repeat the landmark test. Verify the image, coordinates, and overlay before changing detection settings.
5. Save and reload the configuration. Check the active reference again after loading.

If references remain inconsistent, create a minimal test group using the application's documented procedure. Add only acquisition input, the required preprocessing, and the inspection step. Compare that working path against the failing group.

Do not delete the original configuration before preserving its parameters and connections. Rebuilding a large group can conceal the cause while introducing unrelated changes.

For custom acquisition applications, camera acquisition software compatibility is a separate prerequisite. Correct image binding cannot compensate for unsupported acquisition interfaces or incompatible image handling.

Decide whether hardware selection is relevant

A source-binding fault is normally a configuration or application issue. Replacing a camera does not repair a reference to the wrong image output.

When designing a new station, the distinction between area scan cameras and smart cameras helps locate responsibility. A host-based acquisition workflow needs explicit handling of incoming images and application buffers. An on-device inspection workflow still needs correct connections between acquisition, preprocessing, and inspection tools.

The LS-CMR-0053 is a catalog example for an area scan acquisition discussion. Confirm the intended software interface and image-handling requirements separately.

The LS-SMC-0063 is a catalog example for a smart-camera discussion. Do not assume that a particular editor or group-processing workflow is supported without checking the applicable documentation.

Use the camera finder when acquisition requirements justify selecting hardware. Resolve a reproducible binding error first, so hardware comparisons address the inspection task rather than a software symptom.

Verify the repair with a short acceptance test

A successful drawing operation is only the first check. Test the stored geometry and processing behavior as well.

• Single-frame check: Display and process the same saved image. Confirm that the selected landmark lies inside the intended region.
• Coordinate check: Compare the region's numeric position and dimensions with the expected image coordinate system.
• Boundary check: Place regions near each image edge. This exposes missing offsets, clipping, and incorrect axis assumptions.
• Display check: Change viewer zoom and panel size. The selected image pixels should remain unchanged unless editing occurs.
• Sequence check: Process several distinguishable frames. Confirm that each overlay belongs to its corresponding frame.
• Persistence check: Save, close, reopen, and read back the image input and ROI geometry.
• Inspection check: Present acceptable and unacceptable samples. Confirm that the repaired region supports the intended decision.

For precise landmark comparisons, a pixel-step alignment cursor can help distinguish a small coordinate error from visual uncertainty at reduced zoom.

If the ROI deliberately moves with a located feature, verify both stages separately: first the location estimate, then the transformation that places the inspection region. A moving region is not automatically evidence of incorrect binding.

Prevent recurrence and choose the next action

Name acquisition sources and intermediate images by function. Record crop origins, resize factors, and rotation settings alongside the processing configuration. Where the software permits it, store the ROI with its intended image stage rather than treating the geometry as an isolated setting.

After changes to acquisition dimensions or preprocessing, rerun the acceptance test before returning the inspection to production. A configuration can load successfully while its coordinate assumptions are no longer valid.

If the problem persists, prepare a minimal configuration, one saved image, expected ROI coordinates, and screenshots showing both the input reference and displayed source. Send those details through application support so the next investigation starts with reproducible evidence rather than a guessed camera fault.