2D vs 3D camera ROI: where to set it and which one wins

Your 3D camera ships with a viewer tool, and your processing software has its own ROI box. Both crop the image, the manuals rarely say which one wins, so the ROI ends up set twice or not at all. The rule is short: crop pixels as close to the sensor as you can, and filter points as close to the measurement as you can. That puts the 2D ROI in the camera's viewer tool, where it shortens every capture, and the 3D ROI in the processing software, where it gates the point cloud by height. Below are the numbers behind that split: the milliseconds a camera-side crop saves, what it does to the cloud, and when cropping at the camera is the wrong move.

What is the difference between a 2D ROI and a 3D ROI?

A 2D ROI is a rectangle in the image, so many columns by so many rows of pixels; a 3D ROI is a box in millimetres, with x, y and z limits, that keeps only the points of the cloud inside it.

The 2D ROI acts before depth exists: it decides which pixels are read out of the sensor and sent. The 3D ROI acts after: the camera computes depth for every pixel it kept, and the box decides which of those points survive into your measurement. Change the 2D ROI and you have changed the capture. Change the 3D ROI and you have changed only what the processing sees.

One setting lives in pixel coordinates, the other in the camera's metric frame. That single difference drives every priority rule below.

Which ROI setting has priority: the camera tool or the processing software?

Set the 2D ROI in the camera's viewer tool: both places crop the same pixels, but the camera-side cut happens before readout and transfer, so every capture gets shorter, while the software-side cut still receives the full frame.

The two tools overlap for deployment reasons. A camera viewer carries a 2D ROI so the camera is usable on its own, streamed into any host. Processing software carries one so it can trim images from cameras that offer no on-device crop. When both run, the two rectangles intersect: the camera streams its cropped image, and the software crops again inside it. Setting the same rectangle twice buys nothing the second time.

On a smart camera the question never arises, because capture and processing share one tool and one ROI setting inside the same housing.

The bandwidth side of this — what a crop does to the stream into your host — is covered in camera ROI cropping at the source; this page stays with the 3D camera case.

How much capture time does a camera-side 2D ROI save?

In proportion to the pixels you drop: on a transfer-bound link, cropping a 2448 × 2048 mono frame down to a quarter of its area cuts transfer from about 50 ms to about 13 ms per frame.

The arithmetic for a structured-light set-up over GigE:

• Full frame: 2448 × 2048 = 5,013,504 pixels, and at 8 bits each that is about 5.0 MB per frame.
• GigE carries roughly 100 MB/s of usable payload after protocol overhead.
• 5.0 MB ÷ 100 MB/s ≈ 50 ms of transfer per frame.
• Crop to 1224 × 1024 = 1,253,376 pixels ≈ 1.25 MB, and transfer falls to about 12.5 ms.
• Saving: roughly 37 ms per frame.

A structured-light camera does not read out one frame per capture; it projects a sequence. At 12 pattern frames per 3D shot, the saving repeats twelve times: 12 × 37 ≈ 440 ms per capture, most of a second off the cycle when the link is the limit. Fewer rows also shorten sensor readout even when transfer is not the bottleneck, which lifts the maximum frame rate; the multi ROI frame rate arithmetic works through that math for several rectangles at once.

The crop also shrinks what the frame sees of the scene. If the sensor's 2448 columns span 400 mm of conveyor, one pixel maps to 400 ÷ 2448 ≈ 0.16 mm, and a 1224-column ROI covers 1224 × 0.16 ≈ 200 mm. Run that mapping backwards — how many pixels a field of view and a tolerance need — with the resolution calculator:

Does a 2D ROI change the point cloud the camera outputs?

Yes, in coverage, not in accuracy: the cloud shrinks to the scene the cropped images still see, and every remaining point keeps the depth precision it had in the full frame.

For a stereo or projected-pattern camera, depth is only computed where the two views — or the pattern and the sensor — overlap. Cropping the 2D image down to that overlap throws away pixels that could never produce points, which is why the capture speeds up while real coverage survives. Cropping inside the overlap removes genuine coverage: the cloud's footprint shrinks by about the same fraction as the image.

Each depth engine among 3D sensors treats the crop in its own way. A ToF camera crops like any area scan camera, by row and column. A stereo pair keeps only matches inside the cropped overlap. A laser profiler trims the profile line itself, so the saving arrives as fewer columns per profile:

For the stereo, projected-structured-light and ToF families:

Points near the crop edge thin out first, because those pixels carry the least pattern contrast. Give the rectangle margin rather than aligning it exactly to the part.

What can a 3D ROI do that a 2D ROI cannot?

Separate surfaces by height: a 3D ROI keeps only the points inside a z-range, for example 810 to 870 mm from the camera, so the conveyor survives and the wall behind it disappears — something no pixel rectangle can do.

Height is the only axis that does it. In the image plane, the back wall, the fixture above the part and the part itself land inside the same rectangle of pixels, so a 2D crop takes them all or keeps them all. A z-gate tells them apart in one comparison.

It also cuts processing load before your tools ever see the data. A matcher or blob tool on the host scales with the number of points it receives, and the box can drop most of a raw cloud; the point cloud processing load diagnosis starts from exactly that number.

Worked example, from measurements you already have:

• Conveyor surface at a measured 860 mm from the camera.
• Tallest part 40 mm, so the part top sits at 860 − 40 = 820 mm.
• Allow 10 mm for conveyor height variation and part tilt.
• Keep z from 860 − 40 − 10 = 810 mm to 860 + 10 = 870 mm: a 60 mm slab.

Everything past 870 mm — the back wall, the bin behind the station — and everything nearer than 810 mm, such as a gripper entering the field, drops at the filter before your measurement runs. A depth-camera walkthrough of exactly this gate on a one-inch z-layer is in configuring a one-inch Z-layer scan.

This is also why the 3D ROI exists only in the processing software: it filters computed points in millimetres, and the camera's viewer tool, which works in pixels, has nothing to hang it on.

How do I set the 3D ROI without cutting off the part?

Bound it from the measured surface — standoff plus part height plus a 10 to 20 mm margin — in millimetres, in the camera's own coordinate frame, never in pixels and never in the robot's frame.

Two traps clip parts silently. First, axis direction: tools disagree over whether z grows away from the sensor or along the optical axis, and a mounting rotation can swap x and y; the 3D ROI coordinate frame guide walks through diagnosing an inverted box. Second, unit mismatch: a depth scale read in metres against a box in millimetres truncates the cloud at close range, which looks exactly like a part that vanished — see depth scale mismatch.

Margin by station type: 10 mm on a rigid fixture with located parts, 20 mm on a moving belt where parts bounce and tilt.

So which ROI do I set, and where?

Both, in that order: the 2D ROI in the camera's viewer tool as soon as the inspection zone is fixed, then the 3D ROI in the processing software to gate height and strip the background.

They do not compete. The 2D ROI shrinks the capture, the 3D ROI shrinks the processing, and a cell pressed on cycle time needs both. The decision per case:

Choosing the camera comes first, of course: the camera finder lists the current 3D models with their interfaces and viewer tools.

When is setting the ROI in the camera the wrong move?

When the part can appear anywhere in the frame, or when anything downstream was taught on the full image: a camera-side crop is baked into every frame and cannot be undone at the host.

• Random part position: cropping to the usual zone will clip the odd part that lands elsewhere, and the failure is invisible — the part simply is not in the image. Locate on the full frame and gate with the 3D ROI instead.
• Taught coordinates: a locator, a fixed pixel mark or a calibration routine taught on the full frame now sees coordinates shifted by the crop origin. Re-teach, or subtract the offset in your tool.
• Full-frame records: if the cell archives images for audit or retraining, the cropped stream cannot show what happened outside the zone. Keep the camera at full frame and crop copies for the inspection.

What should I check before locking both ROIs in?

One capture with both ROIs off, then one change at a time with a re-check after each: that ten-minute routine catches the two failures that cost days, a clipped part and a silent coordinate shift.

• Capture a full frame; note scene coverage, capture time and point count as your baseline.
• Set the 2D ROI in the camera viewer with 5 to 10 percent margin around the zone, taken at the part's tolerance extremes.
• Confirm capture time fell by about the fraction of pixels you kept, when the link is the limit.
• Set the z-slab from the measured surface, part height and a 10 to 20 mm margin; confirm the tool reads millimetres and the axis direction matches the frame.
• Re-run the locator; if pixel coordinates shifted, re-teach or apply the crop offset.
• Push a part to each tolerance extreme and confirm the cloud still holds it complete.