Repository navigation
fix(rpp): Validate fisheye HOST source coordinates in the ROI-local frame - #13941
Merged
Merged
Conversation
…rame compute_fisheye_src_loc returns a coordinate relative to the ROI (srcX in [0, roiWidth)), and srcPtrChannel is already advanced to the ROI origin, so the load is correct. The bounds check, however, used the absolute ROI rectangle from compute_ltrb_from_xywh_host (x0..x0+w-1, y0..y0+h-1). With a non-zero ROI offset, every mapped pixel left of x0 or above y0 was written black, and pixels past the ROI's local right/bottom edge were accepted. Full-image ROIs were unaffected because the two frames coincide; HIP adds the ROI origin to the coordinate and was already correct. Validate against (0, 0, roiWidth - 1, roiHeight - 1) instead, via a new compute_fisheye_roi_ltrb_local, in the U8, F16, F32 and I8 kernels. The shared nearest-neighbor helpers are unchanged: warp_affine and warp_perspective pass absolute coordinates from the image base and are correct.
✅ All Checks Passed — Ready for Review
📖 Need help? See the Policy FAQ for details on every check and how to fix failures. |
|
🎉 All checks passed! This PR is ready for review. |
Contributor
There was a problem hiding this comment.
🟢 Approval recommended
The localized change consistently corrects the coordinate-frame mismatch while preserving origin-aligned ROI behavior, with no unresolved findings.
No open issues 🎉
What changed in this PR
Fixes blacked-out output in CPU fisheye operations with offset regions of interest (ROIs) by validating source coordinates against ROI-local bounds.
Changes:
- Adds a fisheye-specific helper that computes bounds from
(0, 0)to(width−1, height−1). - Applies the helper to U8, F16, F32, and I8 CPU kernels without changing shared nearest-neighbor helpers.
| File | Description |
|---|---|
| projects/rpp/src/modules/tensor/cpu/kernel/fisheye.cpp | Aligns fisheye validation bounds with ROI-local source coordinates across all four data types. |
Review effort: Balanced
AryanSalmanpour
approved these changes
Oct 27, 2026
Contributor
TheRock Submodule Bump ActivityNewest first
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Motivation
When fisheye ran on the CPU with an ROI that does not start at the image origin, a large part of the output came back black. On a 24x18 ROI at offset (12, 9), 1408 of 2592 output values were wrong. The GPU path and full-image ROIs were correct; only CPU partial ROIs were affected.
Issue
JIRA ID: AICV-260
Technical Details
The CPU kernel computes the source coordinate relative to the ROI and reads from a pointer already moved to the ROI origin, which is consistent. But it checked that coordinate against the ROI's absolute bounds (x0..x0+w-1, y0..y0+h-1). Every coordinate left of x0 or above y0 was rejected and written as black, and coordinates up to x0+w-1 were accepted even though the ROI ends at w-1 in that frame.
Validate against the ROI in the same frame the coordinate is in: (0, 0, w-1, h-1). A new
compute_fisheye_roi_ltrb_localreplacescompute_ltrb_from_xywh_hostin the U8, F16, F32 and I8 kernels. The shared nearest-neighbor helpers are unchanged; warp_affine and warp_perspective use them with absolute coordinates and are correct.Test Plan
Ran the fisheye correctness tests from the GoogleTest suite (#11802) with the skip list disabled, against
developand against this branch:RPP_TEST_NO_SKIP_LIST=1 rpp_tests --gtest_filter='*FisheyeTest*'Compared CPU against GPU output for all four data types (the suite does not cover I8), three layouts and four ROI placements. Ran the full suite, both normal and with the skip list disabled, to check for regressions.
Test Result
960(blacked)96PASS