Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GridSample with bicubic interpolation and border padding #10607

Open
broune opened this issue Feb 21, 2022 · 2 comments
Open

GridSample with bicubic interpolation and border padding #10607

broune opened this issue Feb 21, 2022 · 2 comments
Assignees

Comments

@broune
Copy link

broune commented Feb 21, 2022

I believe that the GridSample op (which recently became an official ONNX op) implementation has a bug on GPU and CPU on line 150 and 210 respectively:

GPU:

grid_x_imgSpace = max(0.0f, min(grid_x_imgSpace, W_in - 1.0f));

CPU:

x = std::clamp(x, static_cast<T>(0), static_cast<T>(W_in - 1));

This is moving out-of-bounds points to the border when using the border padding mode. This is correct for the nearest interpolation mode and, for complicated reasons, it is also correct for bilinear interpolation. However, bicubic interpolation looks at a 4x4 neighborhood around the data point, so for points that are outside the border, but not far outside, it makes a difference to move the point to the border. At the border, there will be no fractional part in that dimension, so "vision" from the point is limited to the border itself and interior points are irrelevant. However, if the point is slightly outside the border, then there is a fractional part and "vision" from that point extends by 2 units into the in-bounds area, which is enough to pick up an interior point and thus an interior point's value can make a difference. Hence moving a point to the border can remove the contribution of interior points to the interpolated value, creating a discrepancy.

As far as I can see, it is correct to remove this logic, as the border padding mode is additionally handled in a different place. My suspicion, however, is that this logic was added for the purpose to address concern number 8 from this bug report I just made against the ONNX spec, about what happens when the grid point coordinates are very large: onnx/onnx#4033 So maybe there is a reason it would need to stay in some form.

To reproduce, any example with a query point slightly outside the border with the border padding mode and bicubic interpolation should trigger it. The input can be 2x2 with distinct values, e.g. {{1, 2}, {3, 4}} and the query point might be (0.4, 1.1). (I didn't try those specific values myself, let me know if that works).

@skottmckay
Copy link
Contributor

@XiyinOSS could you please take a look?

@XiyinOSS
Copy link
Contributor

Thanks for the finding @broune. A PR will come soon.

mtavenrath added a commit to mtavenrath/onnxruntime that referenced this issue Feb 19, 2024
…ect for border padding mode with align = 1.
mtavenrath added a commit to mtavenrath/onnxruntime that referenced this issue Feb 19, 2024
…ect for border padding mode with align = 1.
mtavenrath added a commit to mtavenrath/onnxruntime that referenced this issue Feb 21, 2024
…ect for border padding mode with align = 1.
tianleiwu pushed a commit that referenced this issue Feb 23, 2024
…_test for all EPs (#19562)

I've added NHWC GridSample support to the CUDA EP to reduce the number
of layout transforms. Also I've enabled the full set of GridSampleTests
for all EPs. I've also added the GridSample OpSet 16 to the registered
kernels.

### Motivation and Context
This is the first PR is a series of enhancements of the CUDA EP
improving NHWC support to avoid costly layout transforms between NWHC
and NCHW nodes which are layout sensitive. Also testing was quite
rudimentary for the CUDA EP while it was great for the CPU path. I've
regenerated grid_sample_test.cc enabling tests for other platforms as
well. Those tests resurfaced #10607 again which is fixed as well.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants