Deprecate ImageProjectiveTransformV2

[WindQAQ]

ImageProjectiveTransformV2 seems to be integrated into core TF at tensorflow/tensorflow@2699281 in Jan. We have to deprecate the use of it.

https://github.com/tensorflow/addons/blob/master/tensorflow_addons/custom_ops/image/cc/kernels/image_projective_transform_op.cc

Also, it was unclear to me that ImageProjectiveTransformV2 has been integrated into TF many months ago. Maybe we should check new stuff in TF regularly. Thanks @bhack for pointing out!

cc @tensorflow/sig-addons-maintainers

[seanpmorgan]

@bhack this issue is for what needs to be done to deprecate ImageProjectTransformV2.

Please create a new issue to discuss how we can clarify the tf.image, tfa.image, and Keras image preprocessing relationship. Alternatively, add it to the meeting agenda. and let us know who you want us to try to get to the meeting for in person discussion.

[tanzhenyu]

@bhack this issue is for what needs to be done to deprecate ImageProjectTransformV2.

Please create a new issue to discuss how we can clarify the tf.image, tfa.image, and Keras image preprocessing relationship. Alternatively, add it to the meeting agenda. and let us know who you want us to try to get to the meeting for in person discussion.

Yeah I believe those are separate issues. For ImageProjectiveTransformV2 we could either 1) completely remove it from tfa.image, or 2) keep a reference to core.

[AakashKumarNain]

I believe any redundancy is bad. If we have this in TF core, then I suggest we start with a deprecation warning and remove it gradually in the next version

[gabrieldemarmiesse]

Thanks @bhack for bringing this to our attention! I believe we should replace the body of our implementation and call the one in TF while keeping the same API on our side for backward compatibility. If the TF implementation is the same as ours, the tests should pass. Though we should also keep the C++/CUDA code on our side for a while because if we remove the custom op, people trying to load their models will get an error.

But the biggest problem right now is that we can't access their implementation because it's not exposed in the public API (as far as I know). We could ask the TF team to expose it for TF 2.3? At least it doesn't seem that we're in a hurry.

[seanpmorgan]

We could talk in a new ticket but I think that is the normality of the bottom-up process about recognize the single instance of an issue and trying to find the root process/generalizzation that it is creating this kind of issue.
If we are working on the same or overlapped things but we don't know what we are planning on both sides we will go to generate more and more of these issues in image operations.

If we do it that way then we end up with the mess that is the AutoAugment issue. We don't want to have to dig through issues related to a larger topic to see the high level discussion. Feel free to link to the lower level issues in the higher level discussion not the other way around.

[gabrieldemarmiesse]

@bhack we totally agree with your point about duplication, but the best place to discuss a new process is a new standalone issue where is referenced all other issues where the pain point is appearing.

[gabrieldemarmiesse]

Cleaning up the discussion for the future readers.

[bhack]

I removed all the comments here and also the original comment on the @WindQAQ PR that generated this ISSUE.