kornia: [Bug] warp_perspective does not return the input if used with identity matrix
🐛 Bug
The output of kornia.geometry.warp_perspective
does not equal the input if the identity matrix is used.
To Reproduce
Steps to reproduce the behavior:
import torch
from kornia.geometry import warp_perspective
torch.manual_seed(0)
dsize = (32, 16)
src = torch.rand(1, 3, *dsize)
M = torch.eye(3).unsqueeze(0)
dst = warp_perspective(src, M, dsize)
mae = torch.mean(torch.abs(dst - src))
print(mae.item())
0.14952071011066437
Expected behavior
0.0
Environment
kornia==0.4.1
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Comments: 20 (15 by maintainers)
I agree with the deprecation. It is further supported by the fact that no other library seems to have
align_corners
or equivalent for image-transform-by-matrix functions:In my opinion the addition of an
align_corners
option is confusing, of limited practical use, and increases the likelihood of doing bad things like transforming images and point annotations in subtly different ways despite using the same transformation matrix.I agree with @pmeier that we might add it in the docs to let the users more aware of the differences of the parameter choice. This pic is a nice demonstration.
@Multihuntr assuming that possibly makes sense to get rid of
align_corners
fromwarp_affine
,warp_perspective
. This might requires some work to verify that we don’t break any other component since we highly rely on this operator.@pmeier @anibali @ducha-aiki any opinions about this deprecation ? I think that we introduced support to
align_corners
because pytorch did, but we never discussed the real need for us.Our initial intention here was to mimic opencv behaviour. In the early stages, pytorch had default
align_corners==True
which as showed here is what we mostly support and assume by default. Was later thatalign_córners
was introduced to generate the grid and overcomplicated our logic. Possibly the question is that I from Kornia should be really exposealign_corners
at all and if it makes sense for our users. /cc @ducha-aikiThis is possibly one of the most core functionalities in the lib so I’d love to hear opinions and use cases on that end.
I was investigating how the different libraries handle the sampling issues of interpolating, and I wrote a test script that compared PyTorch, OpenCV and Kornia on a few different settings. There seems to be a few inconsistencies between Kornia and the others. I apologise but I don’t have the solution to it. It may be an issue in the PyTorch functions you call?
cv2.warp_affine
==cv2.warp_perspective
==cv2.resize
==torch.nn.Upsample
(regardless of align_corners)align_corners=False
:kornia.geometry.warp_affine
== source ✔️kornia.geometry.warp_perspective
cuts off bottom right and uses border constant of 0. ❗align_corners=True
:kornia.geometry.warp_affine
testing a 3x3 stretches top-left 2x2 into the space of 3x3. I suspect an off-by-one in indexing. ❗kornia.geometry.warp_perspective
== source ✔️cv2.warp_affine
==cv2.warp_perspective
align_corners=False
:cv2.resize
==torch.nn.Upsample
which is not quite the same as the diagram with blue dots implies;kornia.geometry.warp_affine
!=kornia.geometry.warp_perspective
!=cv2.warp_affine
:kornia.geometry.warp_affine
cuts off bottom right and uses border constant of 0 ❗kornia.geometry.warp_perspective
cuts off bottom right, ends up with a border of 0s ❗align_corners=True
:torch.nn.Upsample
as per the diagram with the blue dots.kornia.geometry.warp_affine
==kornia.geometry.warp_perspective
==cv2.warpAffine
==cv2.warpPerspective
✔️torch.nn.Upsample
.Here's my code (click to reveal)
And here's the output (click to reveal)
On the blue dots diagram (click to reveal)
Specifically when resizing, OpenCV and PyTorch don’t extrapolate beyond the source image boundaries (in contrast to warping, where OpenCV does extrapolate). Instead the interpolation indices get clipped to the image boundary, so when resizing in PyTorch and OpenCV we actually end up with data like this:
This is to explain my earlier comment that it didn’t match the blue dots diagram reference earlier in this issue. The original blue dots diagram is more appropriate for discussions on warping, since you choose how to pad the original image for warping, and thus can extrapolate beyond the original image boundaries.
@edgarriba This should not be closed by the bot, since the bug won’t go away if no one has posted anything new.