Show a circular ROI overlay with a numeric radius on your image

You set an annulus control to the radius you want and nothing appears on the image, because a control holds numbers while the display draws pixels. Draw a circle ROI directly on the display and the numeric entry drops out of the workflow instead. Here you wire the two together: convert the annulus descriptor to an ROI, overlay that ROI on the image, and keep the numeric radius as the single source of truth, in pixels or millimetres, with the one caveat that the drawing path is integer-only. The steps are written for a LabVIEW vision application, where the annulus control lives; the pattern of numbers in and drawn contour out ports directly to any library that separates ROI data from display overlays. The worked example sizes a bore-inspection ring at 10.0 µm/px and shows where the half-pixel display error lands.

Why does my annulus control not draw anything on the image?

Nothing is wrong with your control: an annulus control stores center X, center Y, inner radius, outer radius, start angle and end angle as numbers, and it draws nothing by itself; the circle appears only when a conversion function turns those numbers into an ROI that an overlay function draws.

The control and the picture are separate objects with separate jobs. The annulus control is a front-panel element and nothing more; the Image Display is a viewer for a pixel buffer plus an overlay layer drawn on top of it. A number in a control never reaches that layer on its own, and a circle drawn with the mouse never reaches the control. The bridge is mechanical: one function converts the annulus descriptor into an ROI in image coordinates, another draws that ROI onto the image the display shows. Wire the bridge once and both sides stay in step on every change.

What do I need before I wire the overlay path?

You need four blocks wired to one image: the annulus control, the conversion function that turns an annulus descriptor into an ROI, the overlay function that draws an ROI on the displayed image, and the Image Display itself.

In the LabVIEW vision library those last two are the pair IMAQ Convert Annulus to ROI and IMAQ Overlay ROI. The image can come from a camera, a frame grabber or a file, because the overlay does not care where the pixels come from.

The example column is the bore-inspection ring of the worked example below; the field names are the annulus control's own.

How do I turn annulus numbers into a circle on the image?

The chain is three blocks in series: wire the annulus control into IMAQ Convert Annulus to ROI, feed the resulting ROI and your image into IMAQ Overlay ROI, and show the updated image in the Image Display; the circle follows the numbers within one iteration of the loop.

1. Place an annulus control on the front panel and set a test geometry: center (1224, 1024), inner radius 780, outer radius 820, angles 0 to 360 degrees.
2. Wire the control into IMAQ Convert Annulus to ROI. It returns an ROI whose contour follows those six numbers in image coordinates.
3. Wire that ROI, together with the image you want to annotate, into IMAQ Overlay ROI.
4. Display the updated image in the Image Display: the ring appears on top of the pixels, exactly on the numbers you typed.
5. Put steps 2 to 4 inside the loop that already updates the display, so any control change redraws the ring on the next iteration.
6. Drag the ring in the display whenever you like; the syncing section below writes the dropped position back into the controls.

The ring rides on the same overlay layer that carries pattern-matching results drawn on the image, so the two annotations coexist without interfering; see drawing pattern-matching results on the image for that side.

How do I enter the radius in millimetres instead of pixels?

Convert with the image scale: radius in pixels equals radius in millimetres divided by the scale, where the scale is field of view divided by sensor width in pixels; at 10.0 µm/px an 8.00 mm bore radius is 800 px.

Why does the drawn circle sit up to half a pixel off my radius?

Overlays draw in whole pixels: the annulus-to-ROI path is integer-only, so a radius of 799.6 px lands on 799 or 800 px and sits within half a pixel, which is 5 µm at 10.0 µm/px, of the true value; keep subpixel numbers in the measurement data and round only for display.

Expect up to half a pixel of disagreement and do not assume which way the library rounds. That is the display's business, not the measurement's: run the gauging fit at full precision inside the band and treat the drawn ring as the operator's cue. If a report must show a drawn radius that matches the fitted radius to the pixel, round the value yourself with a fixed rounding rule and draw from that number.

How do I let the operator drag the circle and keep the numbers in step?

Run the conversion in reverse: read the ROI from the Image Display's ROI property, pass it through the paired conversion back to annulus values, and write the results to your numeric controls; one edit anywhere converges within one loop iteration.

The ROI lives on the display's property node, so a mouse-drawn or mouse-dragged circle shows up there. Look for the reverse conversion beside the first one in the same function palette; vision libraries almost always ship the two directions as a pair, so the way back is a lookup, not new code. Guard the loop: write the controls only when the values actually changed, or the write-back triggers a redraw that triggers a write-back. If several image sources feed one display, bind the read-back to the right source, because the mismatch looks like a circle snapping to the wrong part; binding each ROI to the right image source covers that failure. For what the operator may move and what stays locked, see designing the display and ROI interaction.

How do I keep the overlay clean when the radius changes every part?

Redraw on change: clear the previous overlay before drawing the new circle, and when the image updates every frame, apply the overlay to each new buffer so old rings never pile up on the display.

An overlay is stored with the image it was drawn on, and what survives onto the next acquisition depends on the library's overlay handling. Make no assumption: clear, then draw, inside the same iteration that acquires, and you are correct either way. If the geometry is fixed, draw once after set-up and skip the per-frame work; if the center tracks the part, redraw at the locator's rate. A ring that flickers is usually drawn before the display buffer is committed, so draw after the new frame is shown and the flicker stops.

What should I check before this goes on the line?

Check the overlay by numbers before you trust it on the line: type a radius of 800 px, confirm the drawn ring spans 1600 px across the part, and read the overlay back with the library's extraction functions so the fields match what you typed.

• Type 800 px in the outer-radius control: the drawn ring must span 2 × 800 = 1600 px across the center row.
• Read the overlay back with your library's overlay-extraction functions and compare all six fields against the control.
• Feed the angle fields 2π radians once: if the library expects degrees you draw a 6.3-degree sliver, because 2π ≈ 6.28, and the unit mismatch is obvious immediately.
• Shift the circle across the image border and confirm the behaviour you can live with: clipped arc, error, or silent loss of the outside pixels.
• Drag, drop, and confirm the controls show the dropped center while the redrawn ring lands under the cursor.
• Gauge from the fitted edge, never the drawn ring; the span check above tests the display, not the measurement.

Which hardware runs acquisition, overlay and display together?

This loop is light display work: one 2448 × 2048 8-bit frame is about 5.0 MB, so any current vision controller drives the camera, the overlay redraw and the display together; choose the box by camera count and bandwidth, not by overlay speed.

The bandwidth arithmetic is the part that decides hardware: 2448 × 2048 px × 1 byte = 5,013,504 bytes, about 5.0 MB per frame, and at 60 frames per second that is 5.0 MB × 60 ≈ 300 MB/s of acquisition traffic. The overlay adds one contour and a redraw call on top, noise next to the stream. If bandwidth is the tighter problem, cropping the ROI at the camera trims the stream before it reaches the host.

Controllers from the range that cover the usual station cases:

The MV-VC2140-128G40-1T pairs an Intel N-series processor with 8 GB of memory, 3-4 LAN ports and 4 built-in light channels, so the same box can fire the strobe that freezes the part you are circling. The MV-VC3301H-128G66 steps up to an Intel Core i3 with 8 GB of memory and 5+ LAN ports, PCIe expansion supported, and a VM6200Pro license included.

For Camera Link or CoaXPress cameras the acquisition moves to a frame grabber; on GigE, a PoE network card such as the MV-GE2002P adds two camera ports to a controller that has none.

Size the box around camera count and stream rate, start from the accessories finder when a capture card is in the path, and message us through the /contact/ page to have the overlay loop checked against your camera and frame rate; free expert support comes with every order.