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

ksize has no effect in skimage.filters.laplace #5491

Open
grlee77 opened this issue Jul 26, 2021 · 5 comments · May be fixed by #5552
Open

ksize has no effect in skimage.filters.laplace #5491

grlee77 opened this issue Jul 26, 2021 · 5 comments · May be fixed by #5552
Labels

Comments

@grlee77
Copy link
Contributor

grlee77 commented Jul 26, 2021

Description

The discrete Laplacian kernel used internally by skimage.filters.laplace is unaffected by the setting of ksize. The actual kernel generated is always shape (3, ) * ndim. The shape parameter used by skimage.restoration.laplacian only effects the FFT size when creating a Fourier representation of the kernel, but that argument is not even used within skimage.filters.laplace.

We should either deprecate this ksize argument or implement other sizes.

Ideally the spatial laplacian kernel generation should be split into a separate function than the Fourier transfrom used inskimage.restoration.uft.

@grlee77
Copy link
Contributor Author

grlee77 commented Jul 26, 2021

Specifically, ksize is passed as a shape parameter here:

_, laplace_op = laplacian(image.ndim, (ksize,) * image.ndim)

but that shape is only used in the argument to the FFT for the first argument returned by laplacian while the line above only uses the second argument:

return ir2tf(impr, shape, is_real=is_real), impr

@grlee77
Copy link
Contributor Author

grlee77 commented Jul 26, 2021

OpenCV supports odd sizes 3, 5, 7, ... where size = 3 correspond to [-1, 2, -1] and summing the result of applying this along each axis

For ksize = 5 the kernel would be np.convolve([-1, 2, -1], [-1, 2, -1]) with additional repeated convolutions for larger sizes

For larger ksize, I am not sure where the algorithm OpenCV uses to compute the length ksize 2nd order stencils comes from.

For ksize = 1, the specific non-separable 2D kernel

[[0,  1,  0],
 [1, -4,  1],
 [0,  1,  4]]

is used. This ksize = 1 case is what we have implemented regardless of the user's ksize input.

@themnvrao76
Copy link

can I solve this issue?

@themnvrao76
Copy link

I run code and I saw that every time returns (3,3,3) laplace_op, first, i passed k_size as 3 it is returning (3,3,3) second time I passed k size as 5 still it is returning (3,3,3) so I am going to solve this bug

themnvrao76 added a commit to themnvrao76/scikit-image that referenced this issue Aug 31, 2021
This is issue scikit-image#5491 and the main problem was a function only generating kernel size of 3x3 now I added more kernel_size now kernel size can grow up to 31x31 all odd numbers this issue is all about laplacian operator for edge detection
@themnvrao76 themnvrao76 linked a pull request Aug 31, 2021 that will close this issue
@grlee77
Copy link
Contributor Author

grlee77 commented Aug 31, 2021

See #5552 (comment) for a specific example showing exactly what OpenCV does.

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

Successfully merging a pull request may close this issue.

4 participants