System designHow-to

Scale a camera image to fit an HMI widget the right way

Set the widget's width and height to scale a camera image into an HMI layout: the scale-factor math, aspect-ratio checks, zoom limits and SVG overlay handling.

LumaSpec Vision9 min read Share on LinkedIn

On this page 9 sections
  1. 01Why won't the transform and select binding scale my camera image?
  2. 02What width and height does a 4000 × 3000 camera frame need?
  3. 03How do you keep the aspect ratio when the free space has a different shape?
  4. 04What are the steps to set the scaled size and cap the zoom?
  5. 05When should overlays live in an SVG file instead of the image?
  6. 06Which cameras and controllers feed an HMI image panel well?
  7. 07How small is too small for an operator to judge the image?
  8. 08What should you check before signing off the layout?
  9. 09Questions

The camera frame fills half the panel and the scroll wheel is the only thing changing its size — that is the sign the widget never received a real width and height. This walkthrough is for integrators embedding a camera preview or result image in an HMI layout. You will compute one scale factor from the frame size and the free panel area, write it into the widget's width and height attributes, pin the scroll-wheel zoom where you want it, and move limit lines and cursors into an SVG overlay where the transform binding actually works. The arithmetic is identical from a 2.5 MP preview to a 20 MP frame; only the factor changes.

Why won't the transform and select binding scale my camera image?

The transform binding with a select string addresses element IDs inside an SVG asset, so a raster camera frame has nothing for the selector to match; set the widget's width and height attributes instead, and a 0.35 factor was already the right number.

A binding such as '[{"select":"#LimHigh","translate":[0,0]}]' is the documented way to move a drawing inside an SVG file: the SVG transform attribute applies to an element and its children in that asset. A camera frame is a bitmap. It carries no IDs, the selector matches nothing, and the image stays where the layout put it.

The scroll wheel is a third mechanism: a view scale laid over the widget's laid-out size. Zooming magnifies the render without changing the layout, which is why the reserved area never shrinks. Apply your factor through the attributes instead. For a 1280 × 960 frame, 0.35 gives width 448 and height 336 (1280 × 0.35 = 448; 960 × 0.35 = 336). The panel embedding walkthrough with cursors and zoom covers the rest of that wiring.

What width and height does a 4000 × 3000 camera frame need?

In a free area of 520 × 420 pixels, a 4000 × 3000 frame needs width 520 and height 390: 520 ÷ 4000 = 0.130 is the limiting factor, and 3000 × 0.130 = 390 keeps the image undistorted.

s = min(W_free / W_frame, H_free / H_frame) W_widget = W_frame × s H_widget = H_frame × s

Worked example. Reserve 520 × 420 pixels for the image after headers, buttons and margins. A 12 MP USB3 camera like the LS-CMR-0166 delivers 4000 × 3000 frames at 30 fps. The two ratios are 520 ÷ 4000 = 0.130 and 420 ÷ 3000 = 0.140, so s = 0.130. The widget then measures 4000 × 0.130 = 520 wide and 3000 × 0.130 = 390 tall. The frame fills the width exactly and leaves 30 pixels of vertical slack; center the image in that band and the layout is done.

Area scan cameras12 MP USB3 area scan camera, IMX226, 1/1.7" rolling shutter, 30 fps, 4000 × 3000 resolution (LS-CMR-0166)LS-CMR-0166
Sensor format
1/1.7"
Interface
USB3
Resolution
12 MP
Shutter
Rolling
$560.00View partBuild a system with it

Round the factor to three decimals and compute both attributes from the rounded value, so width and height stay a consistent pair.

How do you keep the aspect ratio when the free space has a different shape?

Use the smaller of the two ratios: if the reserved area is square at 520 × 520, the factor stays 0.130 because 520 ÷ 4000 is smaller than 520 ÷ 3000, so the image lands at 520 × 390 and the leftover 130 pixels become padding — 65 top and 65 bottom when centered.

Set 520 × 520 anyway and the vertical stretch is 0.173 ÷ 0.130 = 1.33: every circle in the image becomes an ellipse a third taller than wide, and any edge you judge on screen lies by 33 percent. The opposite shortcut, filling the square by cropping, costs sensor width: a 4:3 frame cropped to 1:1 discards 1000 of its 4000 columns, 25 percent of the field. Fill only when nothing inspected lives in the margins; otherwise letterbox.

What are the steps to set the scaled size and cap the zoom?

The whole job is six short steps: compute one factor, write it into the widget's width and height, leave the stretch mode off, pin the zoom limits, move overlays into SVG, and verify with a checkerboard.

  1. Measure the free area at the panel's native resolution — 520 × 420 pixels in the running example.
  2. Compute the factor once: min(520 ÷ 4000, 420 ÷ 3000) = 0.130 for a 4000 × 3000 frame.
  3. Set the widget's width and height attributes to 520 and 390, the scaled pair, not the raw frame numbers.
  4. Leave the image's stretch or fit mode off (1:1) so the renderer applies no second, silent scaling on top of yours.
  5. Set the zoom-level limits (the maximum and minimum zoom entries in the widget's property list) both to 100 to lock the scroll wheel, or to a 25–200 range to allow review zoom from the new base size.
  6. Load a checkerboard pattern before the real camera is connected: at the correct size its squares stay square at every zoom level.

When should overlays live in an SVG file instead of the image?

Anything drawn on top of the frame — limit lines, cursors, region boxes — belongs in an SVG asset with element IDs, because the transform binding with select can translate only elements that carry an ID inside that file.

Draw the tolerance lines in a small SVG and give each an ID, for example LimHigh and LimLow. A string variable such as OffsetLimitStr carries the binding, and translating #LimHigh by [0, 195] parks the upper line mid-frame in the scaled view: 1500 image rows × 0.130 = 195 widget pixels. Keep overlay and image aligned one of two ways:

  • scale the SVG asset itself to 520 × 390 and keep the translate values in widget pixels;
  • keep the SVG at frame scale and multiply every translate value by 0.130.

Numeric readouts belong beside the image, not on top of it; the region width and height display trick prints them in one compact string.

Which cameras and controllers feed an HMI image panel well?

The layout only cares about the frame's pixel dimensions, so any camera on the controller's GigE or USB 3 ports works; choose the sensor by the smallest feature you must judge on screen, then let the scale factor follow.

Resolution changes only the factor, not the method. A smaller frame shrinks less, so it keeps more screen pixels per sensor pixel in the same widget; a 20 MP frame leans harder on the minimum ratio. Pick the sensor for the defect size you must judge — the next section gives that rule — and let the widget math follow. Three typical choices:

Area scan camerasHikrobot MV-CU020-90GC 2.5 MP Area Scan Camera, GigE, GMAX4002, ColorMV-CU020-90GC
Sensor format
1/1.7"
Lens mount
C-mount
$309.00View part
Area scan cameras12 MP USB3 area scan camera, IMX226, 1/1.7" rolling shutter, 30 fps, 4000 × 3000 resolution (LS-CMR-0166)LS-CMR-0166
Sensor format
1/1.7"
Interface
USB3
$560.00View part
Area scan camerasHikrobot MV-CS200-10UM 20 MP Area Scan Camera, USB3.0, IMX183, 2nd Gen., MonoMV-CS200-10UM
Sensor format
1"
Lens mount
C-mount
$759.00View part

Run acquisition and the panel runtime on one fanless vision controller. The MV-VC2140-128G40-1T pairs an Intel N-series processor with 8 GB of memory and 2 USB 3 ports, and its 4 built-in light channels drive the illumination directly. The area scan camera category and the camera finder filter the alternatives by resolution, shutter and interface.

If the result reaches the panel through a PLC rather than the controller's own runtime, the display path changes; a PLC-side walkthrough for showing vision camera images on an HMI covers that wiring, and the web viewer widget guide covers streaming to a browser panel.

How small is too small for an operator to judge the image?

Keep every feature the operator must judge at three screen pixels or more: a 0.5 mm defect in a 100 mm field spans 20 sensor pixels on a 4000-pixel sensor, which the 0.130 factor shrinks to 2.6 screen pixels — below the line.

Work in sensor pixels first. A 100 mm field across a 4000-pixel sensor is 100 ÷ 4000 = 0.025 mm per pixel, so the defect spans 0.5 ÷ 0.025 = 20 sensor pixels and 20 × 0.130 = 2.6 on screen. An operator scanning at line speed will walk past that. Below roughly three screen pixels, treat the scaled full frame as context, not judgment.

Crop for the call instead. A region of 1000 × 750 sensor pixels covers 1000 × 0.025 = 25 mm of the part; shown in the same 520 × 390 widget, its factor is 520 ÷ 1000 = 0.520 and the defect spans 20 × 0.520 = 10.4 screen pixels. Run both panels side by side: full frame for orientation, region for the pass or fail decision. Where to set an ROI on 2D versus 3D cameras is its own decision, and the field-of-view-at-height guide fixes the millimetres-per-pixel number before any of this scaling.

What should you check before signing off the layout?

Sign off on four passes: a checkerboard that stays square, on-screen text at nine pixels tall or more, a full-rate stream at the scaled size, and overlays that still land on the part after you rescale.

  • Geometry. A checkerboard or grid pattern keeps its squares square at base size and at every zoom level — proof that both axes use one factor.
  • Text. The smallest on-screen label stands 9–10 pixels tall or more; anything smaller gets misread at a glance.
  • Rate. The preview still streams at capture rate — rendering a 520 × 390 copy costs the runtime almost nothing next to capturing 30 fps frames.
  • Overlays. Move #LimHigh to mid-frame and measure 195 pixels from the widget's top edge.
  • Zoom. The wheel respects the limits you set: locked at 100, or bounded 25–200.
  • Persistence. The size survives a project download. A widget that forgets its image on every download is a save fault, not a scaling one — the HMI widget image save fix walks that repair.

When the layout holds, point the system configurator at your camera count and panel plan, or reach us through the contact page if the factor arithmetic fights your toolkit. Neighboring display and streaming guides sit on the systems topic page.

Questions

Does scaling the widget change the camera's frame rate or the inspection result?

No. The widget resizes a display copy; the runtime still receives and processes full 4000 × 3000 frames. Measure and judge on the captured frame, and never export the displayed bitmap as a record: it carries the 0.130 shrink and any overlay graphics baked in. Keep the raw frames for traces.

Should you leave the scroll-wheel zoom enabled after fixing the base size?

Yes, at review stations. Set the zoom limits to a 25–200 range instead of locking both at 100: an operator can then double the 520 × 390 view to 1040 × 780, and the 0.5 mm defect that measured 2.6 screen pixels at base size shows at about 5.2. Above 200 percent the image only blurs.

Can the image size update itself when the layout or camera changes?

Store the frame size with the camera recipe and recompute at load: divide the free area by 4000 and by 3000, take the smaller ratio, and write width 520 and height 390 before the first frame arrives. When a changeover swaps to a different sensor, the new frame dimensions flow through the same two lines of arithmetic with no layout edits.

How much network traffic does a remote preview panel add?

Only what you send it. Scaled locally to 520 × 390, a 24-bit copy is 520 × 390 × 3 bytes, about 0.6 MB per frame. Shipping raw 4000 × 3000 instead is 36 MB, about 60 times more. Send the display-sized copy to a panel on the far side of the link and keep the full frames on the controller.