After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 162247 - Better noise reduction algorithms
Better noise reduction algorithms
Status: RESOLVED OBSOLETE
Product: GIMP
Classification: Other
Component: Plugins
unspecified
Other All
: Normal enhancement
: ---
Assigned To: GIMP Bugs
GIMP Bugs
Depends on:
Blocks:
 
 
Reported: 2004-12-26 05:26 UTC by Shannon Matteson
Modified: 2018-05-24 11:20 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
different despeckle algorithms (38.40 KB, text/plain)
2004-12-27 16:38 UTC, geert jordaens
Details
noise reduction plugin, eclipse 3.3 CDT project with source, user document and Windows executable (670.15 KB, application/zip)
2007-08-02 21:54 UTC, Roland Simmen
Details

Description Shannon Matteson 2004-12-26 05:26:35 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.
Comment 1 weskaggs 2004-12-26 22:52:22 UTC
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.
Comment 2 Shannon Matteson 2004-12-27 00:56:29 UTC
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.
Comment 3 geert jordaens 2004-12-27 16:35:35 UTC
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.

Comment 4 geert jordaens 2004-12-27 16:38:13 UTC
Created attachment 35228 [details]
different despeckle algorithms
Comment 5 weskaggs 2004-12-27 20:25:18 UTC
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.
Comment 6 geert jordaens 2004-12-29 16:39:49 UTC
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.

 
Comment 7 Shannon Matteson 2004-12-29 22:44:24 UTC
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. 
Comment 8 weskaggs 2004-12-30 15:48:14 UTC
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 :-)
Comment 9 Shannon Matteson 2004-12-30 18:36:39 UTC
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! 
Comment 10 geert jordaens 2005-01-01 10:28:56 UTC
Most noise reducing plugins could probably do a better job if they 
where modified to work on individual channels like suggested
in Bug 160005.
Comment 11 Roland Simmen 2007-08-02 21:54:41 UTC
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.
Comment 12 Sven Neumann 2007-08-02 21:58:36 UTC
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.
Comment 13 Roland Simmen 2007-08-03 23:07:54 UTC
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?").

Comment 14 GNOME Infrastructure Team 2018-05-24 11:20:14 UTC
-- 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.