RemapOp
🚧 Documentation is under development
The Holoscan SDK guide is currently under active development. Some sections may be incomplete or change without notice.
Questions? Contact RidgeRun or email to support@ridgerun.com.
-
Overview
-
Build, Run, and Validate
-
Core Concepts
-
Operators and Graphs
-
Tensor Data and Memory
-
Interprocess Communication
-
-
Application and Operator Development
- Building an HSDK Application
- Writing a Minimal Operator
- Typed Parameters and Configuration
- Reading, Writing, and Forwarding Data
- Writing Tensor Operators
- Complete Operator Patterns
- Authoring Runtime Behavior
- Runtime Parameter Updates
- Lifecycle Callbacks and Restart Control
- Performance and Debugging
- SDK Source Map
-
Operator Reference
-
Core Operators
-
Holoscan Camera
-
Holoscan RidgeRun
- Overview
- Build and Installation
- ArgusCameraOp
- V4L2SourceOp
- V4L2UserPtrSourceOp
- BgraToPlanarTensorOp
- RawBayerToBgraOp
- RawBayerToYoloTensorOp
- YuyvToBgraOp
- TensorRtInferenceOp
- DrmDisplayOp
- DrmBgraDisplayOp
- X11DisplayOp
- CudaCompositorOp
- DepthColorizerOp
- FakesinkOp
- FrameSkipperOp
- InterprocessSrcOp
- TestPatternOp
-
-
Migration from Holoscan 4.x
-
Examples
-
Core
-
Holoscan Camera
-
Holoscan RidgeRun
-
-
Benchmark and Use Cases
-
Holoscan vs GStreamer
- Overview
-
Capture and Display
-
Capture and Inference
- Compare the workloads
- Implemented Applications
- Framework Selection
- Interprocess
-
RemapOp
RemapOp samples a CUDA image using a second CUDA tensor of coordinate pairs. Each destination pixel can select a different source position, supporting image warps and lens correction when the application supplies the corresponding map.
The image and map are separate streams with an explicit capture-time relationship. Configure the map's lifetime, coordinate interpretation, output geometry, and synchronization policy; the operator does not generate calibration or substitute an identity map.
Ports and data contract
| Port | Memory | Queue | Trigger | Contract |
|---|---|---|---|---|
input
|
CUDA device | 1 | OnEach or OnAligned
|
HWC/NHWC image: U8 with one, three or four channels, or F32 with one channel. |
map
|
CUDA device | 2 | Selected with input
|
F32 HWC/NHWC tensor with two interleaved coordinate channels. Batch is one or equals the image batch. |
output
|
CUDA device, contiguous | N/A | Same activation | New image at the configured width and height. Rank, batch, type, channels and metadata are preserved. |
Image, map and output must use the same CUDA device. Map dimensions may differ from image dimensions because the map is sampled over the destination grid.
Input arguments
RemapOpParams contains:
| Parameter | Default and Rule |
|---|---|
width, height, max_batch_size
|
Each defaults to one. Positive dimensions and batch 1–65,535; recompile-required. Batch is required on complete load. |
input_interpolation, map_interpolation
|
Both kLinear; nearest, linear or cubic. Area is not accepted.
|
map_value_mode
|
kAbsolute; RemapMapValueMode also accepts normalized absolute coordinates or normalized relative offsets.
|
align_corners
|
false; controls the normalized-coordinate corner convention.
|
border_mode, border_value
|
Constant and {0.F}. Modes are constant, replicate, reflect, wrap or reflect101; values must be finite, nonempty and one or one per image channel.
|
map_synchronization
|
kLatest; may instead be kExact.
|
map_max_age
|
nanoseconds::max(); at least one nanosecond. Choose a useful finite freshness horizon for the application.
|
Fields outside geometry/batch are CompileTime. Both classes are frozen for an accepted plan; use OperatorHandle::set_params() before compilation. The maximum output span is projected as width × height × max_batch_size × 4 bytes, covering U8x4 or F32x1. The projection must fit INT32_MAX.
Input selection
The temporal contract uses OnEach(input), LatestWithin and ReuseLast in latest mode. Each admitted image uses the newest causal map within map_max_age, or a previously selected map still valid under that bound and the runtime's epoch rules. A map publication alone does not trigger a remap. Before a usable map exists, the missing-data rules prevent a nominal image/map activation.
Exact mode uses OnAligned with a zero window and Exact selection on both ports. Image and map need comparable, identical capture times; a merely recent map does not satisfy it. Processing-time arrival order and a matching frame label do not replace the capture-clock contract.
Example
For absolute mode, each pair specifies a source pixel coordinate. An identity map over matching geometry has map[y,x] = (x,y). The complete SDK pipeline instead uses a two-by-two map with pairs (1,1), (2,1), (1,2), (2,2), published once and reused for three frames.
In graph composition, include <chrono> and <holoscan/vision/remap_op.hpp>. With the existing graph:
auto remap = graph.op<holoscan::vision::RemapOp>("remap");
remap.set_params(holoscan::vision::RemapOpParams{
.width = 2,
.height = 2,
.max_batch_size = 1U,
.input_interpolation = holoscan::vision::InterpolationMode::kNearest,
.map_interpolation = holoscan::vision::InterpolationMode::kNearest,
.map_value_mode = holoscan::vision::RemapMapValueMode::kAbsolute,
.map_synchronization = holoscan::vision::RemapMapSynchronizationMode::kLatest,
.map_max_age = std::chrono::seconds{1},
});
Wire the CUDA image source to remap->input and its separately declared coordinate output to remap->map. The checked Tensor publication helper checks allocation, writable access, CUDA copying, commit and emit. Its host arrays have static lifetime through asynchronous copying. Follow that ownership pattern or generate values directly on the GPU; an unchecked allocation/copy sketch cannot establish a valid map.
Build
Follow Build the SDK on AGX Orin for the SDK build and installation. Link the installed holoscan::vision target in the application.