Control vision display window size and screen position

A preview window should fit the operator’s screen without changing the images used for inspection. That requires separate controls for acquisition, analysis and presentation. Resizing the desktop window is not the same as changing the camera’s image dimensions, and shrinking a preview should not move its overlays away from the features they identify. For desktop inspection applications, the method below gives you predictable window placement, proportional image fitting and a repeatable way to diagnose ignored resize requests.

Separate display geometry from inspection settings

Keep three independent configurations: the acquired image, the analysis pipeline and the display viewport. Change only the last one when adjusting the operator interface.

If your processing library opens its own preview, check whether it exposes window geometry controls. When it does not, disable that automatic preview and send its rendered output to a window your application owns. Do not run both display paths unintentionally.

Changing camera settings to make an image fit a screen can alter inspection coverage or calibration. Keep presentation controls outside the acquisition setup described in resetting camera settings before capture.

For an ordinary operator overview, proportional fit is usually the right default. For judging individual pixels, provide a separate native-scale or zoomed inspection view.

Create and place one persistent window

Use a resizable window rather than a mode that automatically sizes itself to every incoming image. Create it once, outside the acquisition loop, and retain a stable handle or identifier.

1. Disable any automatic preview that would create a competing window.
2. Create your application-owned window with resizing enabled.
3. Present an initial image, or a blank canvas with known dimensions.
4. Allow the GUI event loop to process window creation and layout.
5. Request the desired client-area size and desktop position through the toolkit’s documented API.
6. Read back the actual drawable area after layout completes.
7. Recalculate the image transform whenever that drawable area changes.

Some desktop backends need the first presentation and event dispatch before geometry requests take effect. Others accept geometry during creation. Treat that ordering as backend-specific rather than assuming every environment behaves identically.

Distinguish the outer window rectangle from its client area. A request for a 960 × 640 pixel outer window does not necessarily leave that much room for the image: borders, toolbars and status panels consume space.

Save normal window geometry when the operator finishes moving or resizing it. On the next launch, restore it only after checking that it still intersects an available display. A disconnected monitor should not leave the preview inaccessible.

Fit the image without changing its aspect ratio

Measure the image viewport after the interface has completed layout. Use the same coordinate units for its dimensions, image placement and overlay drawing. Convert between logical desktop units and framebuffer pixels explicitly when the toolkit requires it.

For an image fitted completely inside a viewport, calculate one scale factor and center the result:

This is a letterbox fit: the whole image remains visible, with unused space along one pair of edges. Stretching width and height independently removes that space but changes apparent proportions.

Consider an illustrative source image measuring 1920 × 1200 pixels and a viewport measuring 960 × 640 pixels:

• Horizontal scale: 960 / 1920 = 0.5.
• Vertical scale: 640 / 1200 ≈ 0.533.
• Fit scale: min(0.5, 0.533) = 0.5.
• Rendered image: 960 × 600 pixels.
• Horizontal padding: (960 − 960) / 2 = 0 pixels.
• Vertical padding: (640 − 600) / 2 = 20 pixels.

Keep these calculations in floating point until rasterization. If the renderer rounds the destination rectangle, use that actual rectangle for subsequent coordinate mapping.

Apply the same transform to overlays and pointer input

Store inspection results in a documented image coordinate system. Do not overwrite measurement coordinates with their screen positions.

For source-image coordinates, the forward and inverse display mappings are:

In the worked example, an image point at (960, 600) appears at (480, 320). The arithmetic is 960 × 0.5 = 480 horizontally and 600 × 0.5 + 20 = 320 vertically.

A pointer click at (480, 320), measured relative to the viewport, therefore maps back to (960, 600). Reject clicks in the padding before converting them into inspection coordinates.

Two rendering approaches work well:

• Draw annotations onto a display copy at source resolution, then scale that complete image.
• Scale the image first, then transform every overlay using the same destination rectangle.

The first approach simplifies alignment. The second keeps text and line thickness readable at different window sizes. Either approach must use the results belonging to the displayed frame.

If analysis uses a resized or padded input, first reverse that preprocessing transform into source-image coordinates. Window fitting is a separate transform. The guide to camera preview overlays for motion tracking explains additional checks for overlay alignment. If orientation also changes, account for the transform order described in camera image rotation.

Keep display events independent of frame processing

A desktop window needs regular event dispatch to repaint, respond to dragging and process close requests. A long inspection operation inside the GUI callback can make a correctly configured window appear frozen.

Use the GUI thread for window operations where the toolkit requires it. Perform acquisition and analysis separately, then publish a display-ready frame with its matching results. The following is architectural pseudocode, not a particular library’s API:

acquisition_and_analysis_worker:
    acquire image
    run inspection
    publish latest display packet atomically

GUI update callback:
    read latest display packet
    measure current viewport
    calculate fit transform
    render image and matching overlays
    return promptly to the GUI event loop

window geometry callback:
    save actual geometry
    request repaint

A display packet should include the image, matching overlays, frame identifier and relevant timestamps. If the camera SDK reuses acquisition buffers, retain documented ownership or copy the preview data before publishing it.

For an operator overview, a bounded latest-frame handoff prevents old previews from accumulating. Suppose acquisition produces 60 frames per second while the display presents 20. An unbounded queue grows by 60 − 20 = 40 frames each second. After 5 seconds, 200 frames are waiting.

Discarding superseded preview packets does not mean discarding required inspections. Keep inspection records and machine decisions on their own reliable path. For freezes that persist after separating these paths, use the checks in camera preview freezes after the first frame.

Diagnose ignored size and position requests

Desktop geometry is often a request, not an absolute command. The window manager, GUI backend and session type determine what your application can control.

Do not reapply position and size on every frame. That can fight operator actions, create flicker and trigger repeated layout work. Apply initial geometry once, then respond to deliberate layout changes.

For high-density displays, confirm whether the placement API uses logical desktop coordinates while the renderer uses physical pixels. Multi-monitor desktops can also include negative coordinates; those values are not automatically errors.

If the environment does not permit exact positioning, use a supported docked panel, application layout or operator-restored workspace. Repeated geometry calls cannot remove a window-manager restriction.

Choose acquisition hardware separately from preview behavior

Window geometry alone is not a reason to replace a camera. Select area scan cameras for the inspection’s coverage, timing and interface requirements; use the camera finder when those requirements are established.

The LS-CMR-0053 and LS-CMR-0166 are acquisition options to evaluate independently of the display implementation. Their catalog specifications describe the cameras, not the host application’s window-management behavior.

If the application runs on a vision controller, confirm that its installed operating environment supports the intended interactive desktop and GUI backend. A controller’s camera connectivity does not establish whether a particular session allows scripted window placement.

Keep analysis resolution tied to the inspection requirement. The guide to choosing camera resolution for dimensional inspection addresses that decision; preview dimensions address a different problem.

Verify the result before handing it over

Run these checks with both a static reference image and live acquisition:

• Resize the viewport wider and taller. Circles should remain circular, and the whole image should remain visible in fit mode.
• Move the window between available monitors. Check scaling, overlay placement and restored geometry.
• Place markers near all image corners. Confirm that they stay attached while resizing.
• Click known image locations. Verify inverse mapping and rejection of padding clicks.
• Record image dimensions and inspection settings before and after resizing. Presentation changes should leave them unchanged.
• Introduce a slow inspection operation. The interface should remain responsive without showing an ever-growing preview backlog.
• Confirm that closing the preview has a documented effect. Inspection shutdown must not depend accidentally on destroying a window.

A preview close button is not a machine safety control. Keep safety functions independent of this presentation logic.

Save the chosen display mode, geometry policy and coordinate convention with the application configuration. If camera selection is also changing, start with the camera configuration step. For help separating acquisition requirements from display behavior, send the relevant image dimensions, desktop environment and symptoms through application support.