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

Add non-local-means image denoising #16

Open
theotherphil opened this issue Oct 3, 2015 · 2 comments
Open

Add non-local-means image denoising #16

theotherphil opened this issue Oct 3, 2015 · 2 comments

Comments

@theotherphil
Copy link
Contributor

A naive implementation would be extremely slow, so we should probably implement something like this: http://www.gipsa-lab.grenoble-inp.fr/~laurent.condat/publis/condat_resreport_NLmeansv3.pdf.

@csheaff
Copy link
Contributor

csheaff commented Mar 28, 2021

The link above is broken unfortunately. After taking a look at implementations in both OpenCV and skimage, both use a method based on patches weighted by similarity. However, the skimage implementation incorporates an input parameter called patch_distance which limits the search for patches to a distance from the pixel in question - an option that could save considerable time I imagine. There is also a sigma input parameter that can help with robustness when determining patch similarity.

Moreover, skimage provides an optimized version of the aforementioned approach found here and it is used by default. The relevant publication is:

Froment, Jacques. "Parameter-free fast pixelwise non-local means denoising." Image Processing On Line 4 (2014): 300-326.

and it demonstrates qualitatively similar filtering performance while reducing computation time substantially. Here is the discussion leading to its selection.

Here's a skimage demo of the slow vs fast. You can see that the fast version with sigma PSNR is quite close to the slow version with sigma. I inserted timing statements to compare runtime, and the fast version is faster by an order of magnitude.

I'm inclined to pursue the fast version with sigma unless any counter arguments are made, which would be welcome.

@theotherphil
Copy link
Contributor Author

Either option sounds good - we can always add a fast/accurate toggle at a later date if there's a need.

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

No branches or pull requests

2 participants