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

Logic behind shear_* and translate_* #1724

Closed
WindQAQ opened this issue Apr 24, 2020 · 0 comments
Closed

Logic behind shear_* and translate_* #1724

WindQAQ opened this issue Apr 24, 2020 · 0 comments
Labels

Comments

@WindQAQ
Copy link
Member

WindQAQ commented Apr 24, 2020

Currently, shear_* and translate_* do wrap before transformation and unwrap after transformation. I am confused why we have to do these. Usually, when talking about shearing and translation, it is just a kind of affine transformation without doing these things.

I suppose that we previously implemented in that way is because our transform cannot select the extend mode/filling value. So we have to append an additional channel (wrap) before transformation, and check the zeros in that channel after transformation in order to replace the filling value to desired one (unwrap). Once #1721 gets merged, we could revamp the design/API.

The implementation of translate_xy is also confusing. Apart from wrap and unwrap, shouldn't translate_xy(x, [dx, dy]) is equivalent to translate(x, [dx, dy]) if replace is zero? So I think we can deprecate translate_xy after #1721 gets merged. Besides, translating [dx, 0] and then translating [0, dy] should be logically equivalent to translating [dx, dy] together unless there is some coordinate rounding issue when warping the image.
https://github.com/tensorflow/addons/blob/master/tensorflow_addons/image/translate_ops.py#L124-L125

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant