Conversation
…ction and full backwards compatibility" This reverts commit fcd8f84.
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
ℹ️ 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 👍.
| def to_cpu(self) -> "Image": | ||
| if isinstance(self._impl, NumpyImage): | ||
| return self.copy() | ||
| return Image( | ||
| NumpyImage( | ||
| np.asarray(self._impl.to_opencv()), | ||
| self._impl.format, | ||
| self._impl.frame_id, | ||
| self._impl.ts, | ||
| ) | ||
| ) |
There was a problem hiding this comment.
The new to_cpu path copies GPU-backed images by calling self._impl.to_opencv() and wraps the result in a NumpyImage while keeping the original format. For BGRA/RGBA inputs, CudaImage.to_opencv() converts to BGR (drops the alpha channel), yet the returned NumpyImage still advertises BGRA/RGBA. Any later call that assumes four channels (e.g. to_opencv() or to_bgr()) will now fail or use corrupted data because the array only has three channels. This regression did not exist before, when the class carried the raw numpy array unchanged. to_cpu should copy the underlying data without forcing a BGR conversion so that channel counts remain consistent with format.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
@spomichter this is a helper function. It can be, if you'd like to have it included.
| @classmethod | ||
| def from_numpy( | ||
| cls, np_image: np.ndarray, format: ImageFormat = ImageFormat.BGR, **kwargs | ||
| cls, | ||
| np_image: np.ndarray, | ||
| format: ImageFormat = ImageFormat.RGB, | ||
| to_cuda: bool = False, | ||
| **kwargs, |
There was a problem hiding this comment.
from_numpy now defaults to RGB, breaking OpenCV/BGR callers
The helper now defaults format to ImageFormat.RGB instead of ImageFormat.BGR. Existing code that relied on the previous default (and passed OpenCV images without an explicit format) will silently interpret BGR data as RGB, producing swapped color channels throughout the pipeline. Nothing in the commit signals a deliberate API change, and the surrounding codebase and tests historically assumed BGR as the implicit format. The default should remain BGR or the call sites must all be updated to pass format explicitly.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Super useful. @spomichter, this is why you're seeing color channels flipped.
|
This branch has been totally refactored and rewritten #677 |
3 participants
No description provided.