Dynamic device-side cropping with ImageManip on OAK4 S

YWei

Hi team,

I’m running an OAK4-S RVC4 over USB2 and trying to implement dynamic device-side cropping with ImageManip. I need to re-send an ImageManipConfig via manip.inputConfig.send(...) whenever the ROI changes, as the ROI is based on my object detection bounding box, which changes over time.

Here is how I build the ImageManip node:
`manip = pipeline.create(dai.node.ImageManip)

manip.setNumFramesPool(1)
manip.setBackend(dai.node.ImageManip.Backend.AUTO)
manip.inputConfig.setReusePreviousMessage(False)

manip.initialConfig.setOutputSize(128, 128)

source_stream.link(manip.inputImage)

queue = manip.out.createOutputQueue(maxSize=1, blocking=False)`

I update the cropping configuration whenever the ROI changes:
`def build_roi_crop_config(roi, frame_shape, output_size=None):
cfg = dai.ImageManipConfig()
cfg.clearOps()
cfg.addCrop(x, y, w, h)

if output_size:
    cfg.setOutputSize(output_size[0], output_size[1])

return cfg`

Then, when I decide to refresh the ROI:
cfg = build_roi_crop_config(roi, frame_shape, output_size=(128, 128)) roi_manip.inputConfig.send(cfg)

After running for a while, all my preview windows freeze. There is no obvious error or crash message in the terminal.

Interestingly, host-side cropping works fine. The issue only occurs with dynamic device-side cropping. I initially suspected that this might be related to device computation limits, so I also tried reducing how frequently I update and send the ImageManipConfig, but the preview windows still eventually freeze.

My main questions are:

Is creating a new ImageManipConfig and calling inputConfig.send(...) for every ROI change the recommended approach for dynamic cropping?
Is there a different message/configuration approach that would be more appropriate for this use case?

I’d appreciate any thoughts or recommendations. I can provide more details, logs, or a minimal reproducible example if helpful 🙂

Cheers,
Austin

Oskar-Luxonis

Hey YWei - ImageManipConfig is the correct runtime message for dynamic cropping.

The issue is likely manip.inputConfig.setReusePreviousMessage(False). This makes ImageManip wait for a new config message for each input image. Because you send a config only when the ROI changes, ImageManip eventually waits for a config, upstream queues fill, and the preview streams freeze.

For your use case, remove that line or use:

manip.inputConfig.setReusePreviousMessage(True)

Then send a new complete ImageManipConfig only when the ROI changes. A runtime config replaces the full configuration, so include the crop, output size, frame type, and other needed settings in every message.

Keep setReusePreviousMessage(False) only if you send one config per source frame. For that mode, send configs with the matching timestamp and sequence number, including a skip config when there is no ROI. The lossless-zooming example shows this pattern.

Thanks,
Oskar