Skip to content

Make F.rotate/F.affine accept learnable params #5110

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

Open
wants to merge 8 commits into
base: learnable_params
Choose a base branch
from

Conversation

vfdev-5
Copy link
Collaborator

@vfdev-5 vfdev-5 commented Dec 17, 2021

Following #4995 (comment) and that PR,
here is

  • F.rotate
  • F.affine
    that should be able to accept differentiable params and also be jit scriptable.

@ain-soph we can try to merge this PR at first and then you can update your PR based on this one

@facebook-github-bot
Copy link

facebook-github-bot commented Dec 17, 2021

💊 CI failures summary and remediations

As of commit 912dafb (more details on the Dr. CI page):


💚 💚 Looks good so far! There are no failures yet. 💚 💚


This comment was automatically generated by Dr. CI (expand for details).

Please report bugs/suggestions to the (internal) Dr. CI Users group.

Click here to manually regenerate this comment.

@vfdev-5 vfdev-5 force-pushed the check-rotate-autodiff branch from 5bcdd0d to eb826c3 Compare December 17, 2021 15:45
@vfdev-5 vfdev-5 requested a review from datumbox December 17, 2021 16:56
@vfdev-5 vfdev-5 changed the title Make F.rotate accept learnable params Make F.rotate/F.affine accept learnable params Dec 17, 2021
@vfdev-5 vfdev-5 marked this pull request as draft December 17, 2021 18:06
@ain-soph
Copy link
Contributor

Thanks a lot! I'll follow your style to work on other methods.


# RSS without scaling
sx, sy = shear_rad[0], shear_rad[1]
a = torch.cos(rot - sy) / torch.cos(sy)

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

just wondering, could here be division by zero?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, sy = pi/2 and same for sx=pi/2 with tan. IMO shear of ~90 degrees is too much distortion

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe best to just protect against division by exact zero, or point it out in docs

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Docs however say that values between -180 and 180 are valid. I'm not sure how can we protect from zero devision if user requires 90 degree, like how to evaluate tan(pi/2) without getting infinity. Any ideas ?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think it should be solved in this issue since original non-tensor codes also have this problem.
Maybe we can open a new issue about this. The potential solution might be just to modify the docs or clip within a range. 90 degree shearing seems meaningless.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, if it's not guarded against, the docs or a separate issue would be great.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@vadimkantorov please create a new issue for this discussion. Thanks

@vfdev-5 vfdev-5 marked this pull request as ready for review December 22, 2021 08:48
@@ -464,6 +464,7 @@ def test_resized_crop_save(self, tmpdir):


def _test_random_affine_helper(device, **kwargs):
torch.manual_seed(12)
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I had to add this line and fix shear value due to some random jit vs non-jit results mismatch in one pixel

@vfdev-5 vfdev-5 changed the base branch from main to learnable_params January 5, 2022 15:41
@ain-soph
Copy link
Contributor

Hi, @vfdev-5, sorry for being busy during the past semester. I'm currently available in the following month.
I want to know where we are right now and make contribution to this PR.

Is there any problem to merge the current PR? If not, I'll draft the PR for other operators.

@datumbox
Copy link
Contributor

We might need to hold off this PR until the situation on Transforms API v2 is clearer. I think the two can be aligned but to avoid BC breaking changes we need to think them carefully. @vfdev-5 any concerns?

@ain-soph
Copy link
Contributor

@datumbox (Maybe a question not that relevant) I'm currently doing internship at Meta ([email protected]), will that help for making contribution and communicate ideas for the issue?

The basic idea for this PR is to wrap parameters with torch.Tensor instead of plain float to allow gradient computation w.r.t. those parameters, so I personally don't see anything that breaks backward compatibility yet.

@datumbox
Copy link
Contributor

@ain-soph Thanks for the feedback! I've pinged you via the internal chat but for transparency and to keep the community up-to-date I'll summarize why I proposed to wait a little bit.

The current prototype implementation merged on main branch doesn't have the F layer. This high-level layer of functional transforms, which is also the public interface for the users, connects the low-level kernels (PIL, Tensor). In the original new proposal, this layer was removed in favour of exposing directly the low-level kernels. This was done because the new solution uses Tensor subclassing that is NOT JIT-scriptable. So merging the PR means we are doing changes on an API that could be deprecated. Nevertheless, we are currently examining introducing it back to resolve the verbosity of the proposed API on the Transforms. @vfdev-5 has actually an open PR for that at #6219. So waiting a little bit longer to help us finalize the API will allow us to make better decisions. This doesn't mean that we ignore your feature request, just postpone the merge for a bit until the API proposal is finalized. Let me know if you have more concerns, happy to schedule a chat.

@vfdev-5
Copy link
Collaborator Author

vfdev-5 commented Jun 30, 2022

@datumbox at first we can apply this PR's logic to proto low-level ops, e.g. F.rotate -> F.rotate_image_tensor. Next, we can try to apply that to proto's F.rotate. Here i tried to apply that for rotate op: main...vfdev-5:vision:proto-learnable-params
I still have some test issues, but I think this can be fixed.

@ain-soph
Copy link
Contributor

@vfdev-5 @datumbox Would we reconsider this PR since Transfroms V2 API is out?

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

Successfully merging this pull request may close these issues.

5 participants