Add software rotation fallback for devices without hardware rotate (e.g. DaBai DCW)#197
Add software rotation fallback for devices without hardware rotate (e.g. DaBai DCW)#197T-Lemmel wants to merge 1 commit into
Conversation
Devices whose firmware does not support the hardware rotate property (e.g. DaBai DCW) silently ignored color_rotation/depth_rotation. Add a software fallback: in setupDevices(), when OB_PROP_*_ROTATE_INT is not supported, record the requested angle in dedicated *_sw_ members and apply cv::rotate(ROTATE_180) in the image path. Only 180 deg is handled in software since it preserves image dimensions (step / camera_info stay valid). Hardware rotation behaviour is unchanged. Also expose color_rotation / depth_rotation launch args in dabai_dcw.launch.py.
|
@codex review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 6191a29835
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| if (rotation_deg == 180) { | ||
| cv::rotate(image, image, cv::ROTATE_180); |
There was a problem hiding this comment.
Keep camera info consistent with software rotation
When the fallback is active, e.g. DaBai DCW with color_rotation/depth_rotation:=180, this rotates the published image after the CameraInfo was already published above, so the message still describes the unrotated pixel coordinates (cx/cy and P). Consumers that rectify, register, or project the rotated image with that CameraInfo will compute rays for the wrong pixels, especially with non-centered principal points. The software path needs to publish matching calibration/frame data along with the rotated image.
Useful? React with 👍 / 👎.
Summary
Adds a software image-rotation fallback so
color_rotation/depth_rotationwork on devices whose firmware does not implement the hardware rotate property
(
OB_PROP_COLOR_ROTATE_INT/OB_PROP_DEPTH_ROTATE_INT), e.g. the DaBai DCW.Problem
On the DaBai DCW, setting
color_rotation:=180/depth_rotation:=180has noeffect. In
setupDevices()the rotation is only applied when the device reportsisPropertySupported(OB_PROP_*_ROTATE_INT, ...). The DaBai DCW does not supportthat property, so the requested rotation is silently dropped and the image is
published upside-down.
Solution
angle in dedicated members (
color_rotation_sw_/depth_rotation_sw_).cv::rotate(image, image, cv::ROTATE_180)whenthe software fallback is set.
Only 180° is handled in software because it preserves the image dimensions, so
stepand thecamera_infointrinsics remain valid.color_rotation_/depth_rotation_keep their original meaning (the hardware request).Reproduction