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

Remove OpenCV dependency #6

Draft
wants to merge 4 commits into
base: main
Choose a base branch
from

Conversation

himbeles
Copy link
Contributor

  • Replaces OpenCV methods with numpy and scipy implementations
  • Currently breaks the tests involving quasi-exact angle and image comparisons. Perhaps because of Nearest Neighbor interpolation in OpenCV vs. Spline Interpolation in Scipy?

@nelsond
Copy link
Owner

nelsond commented Aug 22, 2022

Unfortunately, image rotation with scipy.ndimage seems to be really slow.

import numpy as np
import timeit

from gridfit.utils import rotate as opencv_rotate
from scipy.ndimage import rotate as scipy_rotate

data = np.random.rand(1000, 1000)

Running timeit on the following code snippets

opencv_rotate(data, np.random.uniform(0, 360))

and

scipy_rotate(data, np.random.uniform(0, 360), reshape=False, order=0)

yields

1.38 ms ± 22.1 µs per loop (mean ± std. dev. of 7 runs, 1,000 loops each)

and

16.1 ms ± 278 µs per loop (mean ± std. dev. of 7 runs, 100 loops each)

@himbeles
Copy link
Contributor Author

Yes, I have noticed that too :(
But to have a fair comparison, warpAffine should probably be called with the cubic interpolation flag.
Also, the interpolation used for rotation really makes a significant difference on the extracted angle (~0.3 deg).

https://docs.opencv.org/3.4/da/d54/group__imgproc__transform.html#ga5bb5a1fea74ea38e1a5445ca803ff121

@nelsond
Copy link
Owner

nelsond commented Aug 22, 2022

The difference actually seems to be negligible for cubic interpolation. I see an increase to 1.93ms (from 1.68ms), is this consistent with your observations?

It still seems that scipy.ndimage.rotate would make things ~10x slower. Considering that find_dominant_angle already takes up to a second for a reasonably sized image, this might become quite annoying depending on the use case.

Maybe making opencv an optional dependency would be a reasonable solution?

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

Successfully merging this pull request may close these issues.

2 participants