[Relax][ONNX] Fix Resize coordinate error with non-integer scales

[cchung100m]

Hi Committers,

This PR fixes issues #19570. Any suggestions would be appreciated if you are available.

[gemini-code-assist]

Code Review

This pull request preserves original spatial scales during ONNX frontend coordinate transformations to avoid lossy ratios, propagating scale overrides through the 1D, 2D, and 3D image resize operations in TOPI. Feedback on these changes highlights a critical typo (sacle_x_override) in resize.py that will cause a runtime NameError, the fact that the newly defined original_spatial_scales in onnx_frontend.py is never actually used or passed to the resize operators, and a minor PEP 8 style violation regarding spaces around keyword argument assignments.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[cchung100m]

/gemini review

[gemini-code-assist]

Code Review

This pull request preserves the original spatial scales in the ONNX frontend resize operations to prevent lossy coordinate transformations with non-integer scales. It updates TOPI resize functions to accept scale overrides and adds corresponding unit tests. The review feedback suggests fixing a typo in a comment and using topi_mode instead of relax_mode in the 3D resize implementation for consistency.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[cchung100m]

cc @tlopex @guan404ming

[tlopex]

Thanks for working on this fix. Preserving the original ONNX scale is the right approach, but I found two remaining correctness gaps.

1. The dynamic-ROI path still drops original_spatial_scales.

When roi_dynamic_vec is present, _impl_v18 calls _emit_resize_topi_dynamic_roi without forwarding the original scales. The nested resize1d/2d/3d TOPI calls therefore continue to derive the coordinate scale from input_size / output_size.

For example, a dynamic ROI input with a 3x3 tensor and scale 2.5 will still use 3/7 instead of 1/2.5. Could we pass the original spatial scales through this helper for all supported ranks and add a regression test?

2. The 2D asymmetric-nearest integer-division optimization ignores the scale override.

For method="nearest_neighbor", coordinate_transformation_mode="asymmetric", and rounding_method="floor", _resize_2d may set use_int_div=True based only on the input and output sizes. get_inx then uses integer division and does not use scale_x_override.

A concrete example is input size 3 with scale 2.1. The output size is floor(3 * 2.1) = 6, so the optimization uses x // 2, while ONNX requires floor(x / 2.1). These produce different pixel mappings. I think the integer division optimization should be disabled when an explicit scale override is provided, unless the override is proven to match the derived ratio exactly