port ColorJitter to prototype transforms #5656
Conversation
💊 CI failures summary and remediationsAs of commit 242a4c9 (more details on the Dr. CI page): ✅ None of the CI failures appear to be your fault 💚
🚧 3 ongoing upstream failures:These were probably caused by upstream breakages that are not fixed yet.
This comment was automatically generated by Dr. CI (expand for details).Please report bugs/suggestions to the (internal) Dr. CI Users group. |
|
|
||
| # TODO: remove this helper if primitive transforms for F.adjust_{brightness, contrast, saturation, hue} are added | ||
| class _ColorJitterHelper(Transform): | ||
| def __init__(self, kernel_tensor: Callable, kernel_pil: Callable, *args: Any, **kwargs: Any) -> None: |
There was a problem hiding this comment.
Can you propose an alternative approach to the nested private class? Here you document quite a few reasons not to use it (logging, instantiation in every call, non-pythonic etc). Should this be a private method for instance?
Also all these weird idioms we are forced to use are papercuts for not having a high-level dispatcher. There are alternatives we could explore that avoid this.
There was a problem hiding this comment.
Can you propose an alternative approach to the nested private class?
I've added a commit that moves the functionality into a method.
Also all these weird idioms we are forced to use are papercuts for not having a high-level dispatcher.
Yup.
There are alternatives we could explore that avoid this.
Do you have anything specific in mind? I've been thinking on this for quite some time, and I haven't found a solution besides having primitive transforms like I mentioned in the code comment or to reinstate the "high level dispatcher kernels".
Summary: * port ColorJitter to prototype transforms * make color module private * address review comments (Note: this ignores all push blocking failures!) Reviewed By: datumbox Differential Revision: D35216767 fbshipit-source-id: 74bda2fd0a315d6d824ec62cb155a320d77c4766
Closes #5528.