Live binary image preview for defect inspection

A camera preview often shows incoming frames before your inspection code runs. That is useful for focusing, but it does not show whether a defect threshold remains reliable as parts move. For a processed preview, build an acquisition–threshold–display loop and send its binary mask to a persistent image display. This procedure covers the loop structure, timing budget, threshold checks and shutdown behavior needed for a usable inspection-development tool.

Choose a processed preview, not another acquisition stream

Use one acquisition owner to obtain each frame, calculate its mask and publish the result for display. Avoid opening a second acquisition session merely to create a preview. Separate sessions can contend for camera access or show different frames from those being inspected.

Keep these responsibilities distinct:

A latest-mask mailbox works well for the display path: a new completed mask replaces the previous unpublished mask. Skipping preview updates is acceptable when the display is only a development aid. Skipping required inspections is a separate issue and needs explicit handling.

For annotations drawn over ordinary images, use the related camera preview overlays guide. Here, the displayed image itself is the processed binary result. The acquisition session architecture guide explains ownership when more cameras are involved.

Before starting, you need a supported acquisition interface, a documented finite read timeout, a repeatable threshold function and a display object that accepts updated image data.

Set separate processing and display budgets

Acquisition rate, processing throughput and display refresh are different quantities. A fast display does not prove that every image was inspected, and a slow preview does not necessarily mean processing is slow.

For a serial processing stage, compare its execution time with the interval between arriving frames:

Use rates in frames per second or updates per second, and times in milliseconds. Processing utilization is an estimate for that stage alone; it excludes acquisition, transfers, operating-system scheduling and other work.

Consider an illustrative acquisition rate of 25 frames per second, with threshold processing taking 8 ms per frame:

• Frame interval = 1000 / 25 = 40 ms.
• Threshold work = 25 × 8 = 200 ms per second.
• Estimated utilization of one serial processing worker = 200 / 1000 = 20%.

Refreshing the preview at 10 updates per second gives a display interval of 100 ms. The processing stage can still inspect every acquired frame while the preview shows only selected results.

Measure latency with timestamps rather than deriving it from refresh rate alone. For one illustrative frame, suppose these measured intervals apply:

This measures arrival at the software display stage, not the instant the monitor emits the corresponding pixels. Use synchronized camera timestamps if your measurement starts at exposure; do not subtract timestamps from unrelated clocks without establishing their relationship.

Build the acquisition–threshold–display loop

Create the camera session and display once, then update their data. Repeatedly creating windows, axes or image objects adds overhead and makes stopping harder.

Use this implementation sequence:

1. Open the camera through its supported acquisition interface and apply the intended inspection settings.
2. Create an image display with a fixed binary intensity range and a black-and-white palette.
3. Start an acquisition worker that owns the camera and processes frames with finite read timeouts.
4. Publish each completed mask, its frame identifier and timing information into a bounded mailbox.
5. Let the GUI event loop update the existing image object at the chosen preview rate.
6. Route window closure, stop-button actions and worker faults into the same shutdown procedure.

The following is architectural pseudocode, not an API for a particular software package:

GUI startup:
    create persistent window and image object
    set display range to binary values
    create synchronized latest-mask mailbox
    start acquisition worker
    schedule periodic GUI updates

Acquisition worker:
    try:
        open and configure camera
        start acquisition
        while stop has not been requested:
            frame = read frame with finite timeout
            if timeout:
                apply timeout policy
                continue
            mask = threshold selected intensity channel
            publish owned mask and metadata atomically
    catch error:
        publish worker fault
    finally:
        stop acquisition if started
        release camera if opened
        signal worker completion

Periodic GUI update:
    if mailbox contains a newer mask:
        obtain a safe snapshot
        replace existing image data
        update timing and status labels
    process stop requests and worker status

Window close request:
    request worker stop
    request documented read cancellation if supported
    keep GUI responsive until worker completion
    cancel GUI updates and destroy display

Keep GUI operations on the thread required by your display framework. The worker should publish data, not manipulate GUI objects directly.

Give the mailbox its own storage or use a documented ownership-transfer mechanism. Some acquisition interfaces reuse frame buffers; retaining a reference after returning the buffer can produce changing or corrupted images. The same concern applies if you overwrite the mask while the GUI reads it.

When a display update runs late, schedule the next future update instead of replaying missed refreshes. Catching up with old preview images defeats the purpose of a live view.

Verify mask polarity before adjusting the threshold

Define what white means before interpreting the image. For dark defects on a brighter background, one possible rule is:

For bright defects, reverse the comparison. Neither polarity is inherently correct; the inspection decision must match the selected convention.

Test the display using a known all-false mask, an all-true mask and a simple synthetic pattern. These checks distinguish threshold errors from display-range or palette problems.

Then inspect a known acceptable part and a known defective part. Sample intensities inside the defect and background rather than choosing a threshold solely by appearance. Also confirm whether equality belongs to the foreground or background, since quantized pixels can lie exactly at the threshold.

Logical masks, byte images and floating-point images may have different display conventions. Set the range explicitly rather than allowing automatic contrast scaling to reinterpret each frame.

Choose the input intensity deliberately. A color frame may require a documented luminance conversion or a selected channel. Changing that conversion changes the numerical meaning of the threshold, even when the scene appears similar.

Stabilize the image before chasing threshold changes

A fixed threshold becomes unreliable when illumination, exposure or gain changes the intensity distribution. Start with fixed acquisition settings and controlled lighting when the inspection permits it.

For an illustrative 8-bit image, suppose sampled defect intensities lie between 45 and 70, while acceptable background intensities lie between 150 and 190. A threshold of 110 separates those particular samples. It does not establish a production setting until you test variation across parts, positions and operating conditions.

If illumination changes enough that background values enter the defect range, threshold adjustment alone may not restore separation. Diagnose lighting geometry, ambient light, saturation, motion blur and focus first.

Use the exposure and gain units guide when camera settings are expressed in unfamiliar raw values. The contour jitter under automatic exposure guide explains why changing image brightness can move threshold-derived boundaries.

Adaptive thresholding can help with slowly varying backgrounds, but it also introduces a neighborhood size and sensitivity setting. Test whether those settings suppress large defects or exaggerate texture. It is not a substitute for repeatable illumination.

If you apply erosion, dilation or component-size filtering, label the displayed mask accordingly. During development, retain access to the unfiltered threshold mask so cleanup operations cannot quietly hide relevant defects.

Make stopping and faults predictable

A stop button cannot work reliably if a blocking acquisition call prevents the application from processing its event. Use a separate acquisition worker or an event-driven acquisition mechanism, together with supported timeout or cancellation behavior.

Distinguish an isolated timeout from a persistent acquisition fault. A timeout policy might permit a limited retry sequence, then request shutdown and show a fault. Select the limit for the application's expected trigger intervals; an externally triggered camera may legitimately wait between images.

Do not release the camera from the GUI while its worker is still reading, unless the acquisition interface explicitly documents that operation. Request stopping, let the owner finish or cancel its read through the supported mechanism, then release resources in a guaranteed cleanup path.

Handle these cases explicitly:

• Normal stop after continuous operation.
• Window closure during acquisition.
• Camera disconnection or transport failure.
• An exception inside the threshold function.
• Failure after opening the camera but before acquisition starts.
• Restart after the previous session has fully stopped.

A failed worker must also change the display status. Leaving the last mask visible without a stale-image warning can make a stopped inspection look healthy.

For intermittent delivery problems, use the camera acquisition failure troubleshooting guide. Do not hide transport faults by repeatedly reopening the device inside the processing loop.

Choose hardware around the inspection requirements

Start with the required field of view, defect sampling, motion tolerance and supported software interface. The preview loop does not establish whether a camera has enough resolution or whether the inspection can meet cycle time.

For host-side processing, compare area scan cameras through the camera finder. The LS-CMR-0395 is a mono, global-shutter, GigE camera with a C-mount lens mount. Confirm acquisition-library support and the required operating mode before selecting it.

Vision controllers are relevant when acquisition and processing will run in a dedicated vision appliance. The MV-VC2101-128G40-NN is a vision-controller option. Verify operating-system support, software licensing, camera compatibility and measured processing performance separately; the presence of camera connections does not validate your application.

Smart cameras and vision sensors offer a different architecture when processing is performed on the device. Before choosing that route, confirm that its supported tools can produce the required mask and expose it for live viewing. An inspection result output is not necessarily a downloadable binary image stream.

The usual host-processing answer is wrong when your existing device already provides a supported processed-image display that meets the task. Conversely, an integrated device is unsuitable if it cannot expose the intermediate image needed for development or diagnostics.

Commission the preview before relying on it

Use this short acceptance checklist to turn a working demonstration into a repeatable development tool:

• Image identity: verify that each displayed mask carries the identifier of the frame that produced it.
• Binary meaning: confirm that black and white represent the intended background and defect states.
• Threshold stability: test acceptable and defective samples across the expected operating range.
• Timing: record processing duration, result age and dropped preview updates independently.
• Queue limits: slow the GUI deliberately and confirm that memory use does not grow continuously.
• Fault visibility: interrupt acquisition and confirm that the last image is marked stale or replaced by a fault state.
• Resource cleanup: repeat start and stop cycles, then confirm that the camera can be reopened normally.
• Inspection separation: verify that suppressing preview updates does not suppress required decisions or result records.

A binary preview is a diagnostic view, not proof of defect-detection performance. Validate the inspection against representative labeled samples and a defined acceptance criterion independently of how responsive the window feels.

Once the loop passes these checks, use the camera system configurator to select acquisition hardware. For compatibility questions, send the intended image size, acquisition rate, processing environment and timing measurements through application support.