This method is work well for me.
Thank you.
Hi, I also noticed this question in the official docs. May @bnehoran have a look at here? I think the final reflected x'' should be 0.5
As the documentation stands now, it is ambiguous in which order the coordinates x and y should come in the grid argument. It may seem obvious to you that x should come before y in each coordinate pair, but that was not obvious to me, and I in fact assumed that y should come before x, because for the 4D tensor that you sample the points from, the shape is (batch_size, channels, rows, columns), where rows correspond to the y-coordinate and columns to the x-coordinate (and having the y-dimension coming before the x-dimension for the indices of tensors/arrays is pretty much standard in many libraries).
It took me a good while to figure out why the output of my network had so strong artifacts, which could have been prevented if the documentation had specified in which order they come. (It actually looked kind of good but not quite right, so the network had probably learned to flip the image along the diagonal. My output was another image.)
Hi all,
Thanks for all the explanations. One point I understood here, but might be misleading in the documentation about zero padding : “padding_mode="zeros": use 0 for out-of-bound grid locations" made me think any point in parameter “grid” outside of the [-1,1] would give an output value of 0.
In practice, padding_mode=“zeros” uses 0 for out-of-bound “input” grid locations.
What confused me was that the requested coordinates parameter is called “grid”, while the term “grid locations” in padding_mode explanation points the vertices of “input” parameter…
If it seems confusing to others too, it might need a reformulation in the doc?