[Bug] get_rotation_matrix_2d should still work isotropic scale factor
See original GitHub issue🐛 Bug
https://github.com/kornia/kornia/pull/646 removed isotropic scale factor in favor of non-isotropic (x,y) scale factor
This is a breaking change for any library using get_rotation_matrix_2d
(ie. Lucent)
Expected behavior
I suggest allowing both isotropic and non-isotropic scale factors.
Issue Analytics
- State:
- Created 3 years ago
- Comments:6 (2 by maintainers)
Top Results From Across the Web
cv2.getRotationMatrix2D() | TheAILearner
Positive values mean counter-clockwise rotation (the coordinate origin is assumed to be the top-left corner). #scale: Isotropic scale factor.
Read more >mmdet.core.mask.structures — MMDetection 2.24.0 documentation
This function is mainly used in mask targets computation. ... the center of the image will be used. scale (int | float): Isotropic...
Read more >Python 2.7.3 + OpenCV 2.4 after rotation window doesn't fit ...
Any parts of your transformed image that don't lie in that region will be cut off. Here's Python code to rotate and scale...
Read more >Image Rotation and Translation Using OpenCV - LearnOpenCV
an isotropic scale factor to resize the image. This can be a floating point value. For example, a value of 1.0 will keep...
Read more >Python OpenCV - getRotationMatrix2D() Function
getRotationMatrix2D () function is used to make the transformation matrix M which will be ... scale: scaling factor which scales the image.
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
I generally agree that it makes sense for low-level functions to accept primitive parameters.
However, in this case (a breaking change to a low-level function), I’d recommend temporarily allowing isotropic scale factors with some sort of deprecation warning.
A warning will give owners of kornia dependent code bases some time to react to the change and will ensure that everything keeps functioning. I don’t think it’s good practice for people to find out about changes to dependencies because functionality stops working.
Sure this can be closed.