GNOME Bugzilla – Bug 162247
Better noise reduction algorithms
Last modified: 2018-05-24 11:20:14 UTC
The current noise reduction algorithms rely on apparently reducing the sharpness of the image to reduce noise. I would like to see an algorithm that could reduce noise without reducing sharpness.
So would we all. Unfortunately there is no such thing as a perfect solution, because there is no 100% reliable way of statistically distinguishing between noise and "signal". Anyway, GIMP comes with several filters that try to reduce noise while reducing sharpness as little as possible: Despeckle, Selective Gaussian Blur, and NL Filter. There are a couple more available from the registry. Still, it would certainly be nice to have better ones, and specific suggestions are welcome. Actual implementations as plugins, of course, are even more welcome! Rather surprisingly, a search didn't reveal anything that looks like a duplicate, so I'll go ahead and confirm this.
My background does not include programming at the level to which this calls for attention, but I have a theoretical way to improve noise that I can suggest. I am not sure it would be feasible, but here goes. Imagine mapping an image as a three dimentional representation of light and darkness. The brighter the pixel, the "higher" it goes on the "map". Now, if you had no noise in the image, you would find that the "map" was pretty smooth even at the pixel to pixel level. But add in noise, and that smoothness begins to resemble the pits and lands of a CD as the uniformity of the pixels' brightnesses becomes more and more different because of the noise. Maybe even egg-crate packing foam would be a good visual representation. The solution seems to be analyzing a given area and determining the "average trend" for brightness, and then making all those little pits and lands conform to that average. This would not be a linear analysis, though, it would have to be a 3-d analysys in order to be accurate. In addition, there would have to be an algorithm in place to prevent the effect from looking like the oilify effect that gives an oil painting-like appearance to images. I have noticed that in some of the noise reduction algorithms, this begins to show up and sometimes has very obvious (and bad) effects on larger areas of the image. The solution I propose for this would be to do a second analysis that integrates each area that has been adjusted with four other areas which each intersect the first. For instance, each area that has been adjusted might be 24 pixels by 24 pixels. The four areas to have it integrated with might each share a 12x12 pixel corner with the original, so that all four of the other areas intersect at the center of the first, and each corner of the first square touches the center of each of the other four. The only thing I can see that might be a bad idea for this is that in the end, each area would have been adjusted twice. So perhaps pass 1 would divide the image into discrete areas and adjust them as suggested above, and pass 2 would smooth the differences between the edges of each area adjusted in pass 1. Of course I am under no illusion that my suggestions are unique, or even possible, but this is what I envision.
As for the despeckle plugin the algorithm changed recently. Instead of using the median value for each channel seperatly the current implementation uses the median of the intensity. Using the median of the pixel intensity assures that no new color's are introduced in the image. (I think this the brightness thing) I also had 2 other algorithm's in test that handle the colors better being : * Fast Modified Vector Median Filter (FMVMF) * Distance directional filter Those 2 are very expensive to perform because the work on complex numbers and vector distances.
Created attachment 35228 [details] different despeckle algorithms
I tried the code from the attachment. You're right about the new algorithms being expensive! The FMVMF looks like it may perform a bit better than the standard median filter, at least in some places. I didn't manage to discover any settings that caused the DDF to actually alter the image -- it always just seemed to crank for a while and then do nothing.
before the median was calculated on each color channel. which lead to introducing new colors. Sicne 2.2 the median is calculated on the pixels intensity. The pixel with the median intensity is then selected to replace the "speckle". The DDF and FMWMF filters are just another way of determing the most suitable pixel to replace the "speckle". I also had 2 other algorithm's but they did not perform well. If the DDF does not work correctly then probably I have lost the working code. Anyway : DDF anf FMWMF where the fastest after de median based in intenity and quick median select.
I'm sure it would not be suitable for all cases, but is it possible that you might be able to create a sort of "noise map" by determining the difference between an image with no noise, and the same image with noise? Kind of like unsharp mask, I guess, if I understand how that works. You could maybe take an image created at ISO 100 and one created at 200 and 400 and 800 and 1600 and 3200 and determine the different levels of noise and the trend towards increase or decrease, and then perhaps have the algorithm search out that sort of thing in some way and "undo" it. Maybe having the option to calibrate the "despeckle mask" by having the image be examined at lower and higher film/sensor speeds? That might help according to the specific make of camera... This isn't something you haven't already thought of, is it? :) Just trying to help.
There are many different types of noise, with tremendously varying statistical properties -- for example, the noise caused by dust on a lens is completely different from the noise caused by CCD fluctuations in low-light conditions. Also, a texture that is noise in one situation can turn out to be signal in another. I don't want to discourage you, but the fact is that it is 100 times easier to come up with ideas in this domain than to implement them in working code, and no idea ever survives confrontation with real photographs without massive reworking. So feel free to suggest ideas, but don't be surprised if nobody is quick to take you up on them :-)
I completely understand about how unlikely it is my ideas will have earth-shattering effect on the digital noise of the world. :) I've done some coding and I know how ideas have to be shot down and reworled and such, I'm just not up to snuff for the level of math or C proficiency this requires. I figured that since that is the case, in order for me to participate, the only thing I have left to offer is research (which isn't going to do well if I don't know enough about what I am researching mathematically) or ideas. So, no, I won't take offense or get upset if my ideas don't pan out. But I am interested in helping however I can. That's more than I can say for a lot of people I know who just say "Gimp can't do X. It sucks." I use GIMP in my photography business all the time, and it's not perfect, but it certainly doesn't suck. I just want to see it improve, and unfortunately, my area of expertise does not coincide with what would be useful towards that end very much. I really appreciate you guys (nd gals, if there are any) even responding at all to my request!
Most noise reducing plugins could probably do a better job if they where modified to work on individual channels like suggested in Bug 160005.
Created attachment 92950 [details] noise reduction plugin, eclipse 3.3 CDT project with source, user document and Windows executable This noise reduction plugin uses a modified Gaussian blur algorithm to preserve sharpness and details by comparing the noise level with contrast of image details. The goal was to have a noise reduction plugin which is easy to use and has reasonable speed. It has been developed under Windows using Eclipse 3.3 with CDT and MingW for GIMP 2.2.17. The project settings have to be adjusted for the include directories and library path.
Please upload this plug-in to the plug-in registry at registry.gimp.org. If you think it should also be attached here, then all we are interested in is the source code.
The plugin has now been uploaded to the plug-in registry at registry.gimp.org (sorry, I just followed the recommendation in FAQ, "2.3 How do I get my plug-in included in the GIMP?").
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gimp/issues/111.