Nothing in a dataflow carries fx, fy, cx and cy except the camera, and every pixel of a depth map needs them to become a 3D point. The node now accepts them so whatever computes that next has them to hand. They are read from two places because dora-zed publishes them twice: the camera_info message, and the metadata of every frame. The per-frame copy is not redundant -- camera_info goes out once per camera session, so a viewer started after the camera would otherwise never see it, and reading frame metadata means wiring the input is optional even for a camera that publishes it. A nine-element row-major K is accepted alongside the compact [fx, fy, cx, cy], since that is how ROS spells the same model in sensor_msgs/CameraInfo. The model is drawn under the caption rather than only stored. A depth map read through the wrong intrinsics looks entirely plausible, and this is where that becomes visible. as_float32 moves to a payload module: camera_info arrives as a raw byte slice for the same reason the depth map does, and the reinterpretation is now shared rather than written twice. Verified with dora-cli 1.0.1: validate passes with four contracts injected on each side, the dataflow runs to a clean exit, and a composed frame was rendered and inspected with the model drawn on it.
19 lines
598 B
Python
19 lines
598 B
Python
"""Reading raw dora payloads, independently of what they mean."""
|
|
|
|
import numpy as np
|
|
|
|
|
|
def as_float32(storage) -> np.ndarray:
|
|
"""Read a payload as float32, whether it arrived as floats or as bytes.
|
|
|
|
A node that sends its payload as a raw byte slice -- which is what a C++
|
|
node does -- produces a UInt8 arrow array even though its manifest declares
|
|
Float32, so the buffer has to be reinterpreted rather than converted.
|
|
"""
|
|
buffer = storage.to_numpy()
|
|
|
|
if buffer.dtype == np.uint8:
|
|
return buffer.view(np.float32)
|
|
|
|
return buffer.astype(np.float32, copy=False)
|