Fix camera setup review follow-ups - #21
Conversation
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 40ea2ebbb1
ℹ️ 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 args.left is None: | ||
| args.left = "0" if args.backend == "opencv" else "left" | ||
| if args.right is None: | ||
| args.right = "1" if args.backend == "opencv" else "right" |
There was a problem hiding this comment.
Map legacy lane ROIs when defaulting OpenCV IDs
When --backend opencv is used without explicit IDs, these defaults change the runtime camera IDs to 0/1; if the operator still has a legacy configs/lane_roi.json keyed by left/right, load_lane_polygon() only checks the exact runtime IDs and silently falls back to the centered ROI. That makes the newly fixed default OpenCV path ignore saved lane calibration for those rigs, so either map the legacy left/right entries onto the numeric defaults or reuse the existing runtime ROI loader that has that fallback.
Useful? React with 👍 / 👎.
What changed
0/1, while UVC and simulator backends retain logical IDsleft/rightWhy
These changes address the still-valid review findings on PR #8 and PR #6. The old hardware guide could direct field testers toward unsuitable rolling-shutter cameras, and the OpenCV CLI failed at startup when its backend was selected without explicit camera indexes.
Validation
git diff --checkpassedReview references