refactor: speedup int8 resize

[sovrasov]

Summary

• In common resize, input image is not converted to fp32, unless it was already an fp array

Why

• Most of cameras return uint8 images, and resize of this type is the most effective on CPU

Results on 2x 1920x1080

Input dtype	Median latency
fp32	20.728 ms
uint8	1.164 ms

Validation

• Unit test that compares fp32 vs int8 resize result

Breaking changes

• None

[Copilot]

Pull request overview

This PR refactors ResizePreprocessor to avoid converting uint8 images to float32 before resizing, improving CPU resize performance for the common camera-output dtype while preserving the existing float32 output contract.

Changes:

• Keep uint8 inputs as uint8 through resize/padding, and normalize to float32 only at the end.
• Switch the internal resize helper to operate on BHWC (channels-last) to better match OpenCV’s expected layout and reduce transposes.
• Add a unit test asserting uint8 resize matches float32 resize within quantization error.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
src/physicalai/inference/preprocessors/resize.py	Refactors resize path to operate in BHWC and delay uint8 normalization until after resize/pad.
tests/unit/inference/preprocessors/test_resize.py	Adds coverage comparing uint8 vs float32 resize outputs for equivalence within quantization error.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[alfieroddan]

Thanks!

Only edge case I can think of Depth images may wish to resize in different modes other than cv2.INTER_LINEAR but can save for a different PR.