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 156545 - dilate/erode mis-named (refer to opposite operations)
dilate/erode mis-named (refer to opposite operations)
Status: RESOLVED FIXED
Product: GIMP
Classification: Other
Component: Plugins
2.0.x
Other All
: Normal minor
: 2.4
Assigned To: GIMP Bugs
GIMP Bugs
: 158231 168284 349746 768741 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2004-10-27 04:15 UTC by Kenn Heinrich
Modified: 2016-12-09 14:19 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Swap erode and dilate (1.07 KB, patch)
2006-02-16 17:47 UTC, Dave Neary
accepted-commit_now Details | Review

Description Kenn Heinrich 2004-10-27 04:15:27 UTC
I expect erode to darken the image, dilate to brighten it. GIMP seems to do the
opposite. See for example 

http://www.cee.hw.ac.uk/hipr/html/erode.html#1

The GIMP documentation is consistent with its behaviour, however AFAIK both are
contrary to the usual definitions in grayscale morphology.
Comment 1 Sven Neumann 2004-10-28 11:04:03 UTC
Almost impossible to change that now. The PDB functions are there for a while
and if we change the semantics, other scripts will break.
Comment 2 Sven Neumann 2004-11-06 18:44:06 UTC
If the plug-ins are really misnamed, perhaps we should do this change. But then
we should do it before 2.2.0 is released.
Comment 3 Michael Natterer 2004-11-08 11:52:54 UTC
Well, I expect dilate and erode to work on the pixel areas' outlines,
not on their color values. Actually they are properly defined only
for one-bit (b/w) images, so to make them work on gray and rgb images,
one has to define what the "area" is. The arbitrary decision in
the GIMP plug-in was that "whiteish" areas are the background
and "blackish" ones are the foreground (the "object" to erode
or dilate).

Don't let yourself fool by the images on that web page, they have
just randomly chosen black for the background and white for the
object.

Resolving as NOTABUG since it works as expected.
Comment 4 Sven Neumann 2004-11-14 01:55:06 UTC
*** Bug 158231 has been marked as a duplicate of this bug. ***
Comment 5 Joao S. O. Bueno 2005-02-23 18:27:54 UTC
*** Bug 168284 has been marked as a duplicate of this bug. ***
Comment 6 Dimitri Androutsos 2005-02-23 18:45:11 UTC
The operations are most definitely incorrect!

The filters have been misnamed...they need to be flipped.

EROSION is a "min" operation and by definition will darken images and remove
small bright details.  DILATION is a "max" operation that brightens images
overall, removes small dark regions...image looks like it has "bloomed".

References to uphold this:

Gonzalez & Woods, Digital Image Processing, 2/ed, pg. 550-553

..and there are many more.

Also, I have studied morphology quite in-depth while I pursued my doctorate in
the area of image processing.  So I have a very good grasp of what these should do.

If you all need more nitty-gritty proof, I guess I can go through the code and
prove this.
Comment 7 Dimitri Androutsos 2005-02-23 18:46:01 UTC
I think this should be re-opened.
Comment 8 weskaggs 2005-02-23 19:20:15 UTC
I am going to reopen this as you request, but I'm not quite convinced that
comment #6 adequately addresses the points made in comment #3.  The problem is
that, even agreeing that erosion is a "min" operation and dilation is a "max"
operation, the meanings of "min" and "max" may not be well-defined.  If you
assume white = 0, black =1 they mean one thing, but if you assume black = 0,
white = 1 they mean the opposite.
Comment 9 Michael Natterer 2005-02-23 19:24:10 UTC
The literature seems to diverge here. What I learned is that dilate/erode
are defined in terms of foreground/background and *not* in terms of
min/max, and the definition of foreground/background in GIMP is that
white is background and black is foreground.

We need to figure which of the various books is right (if that's possible).
Comment 10 Dimitri Androutsos 2005-02-23 19:35:55 UTC
I agree that the assumption of white/black = 0/1 or vice versa will affect the
result.

This is true and if this is what GIMP is doing then the results are consistent.

But if you read the literature you will see that all literature assume that
black=0.  As I write this, I have 3 image processing books in front of me:

-Gonzalez and woods (digital image processing)
-A.K .Jain (fundamentals of digital image processing)
-Sonka, Hlavac, Boyle (image processing, analysis and machine vision)

...all three are consisten in how they treat morphology and results that are
shown (especially gonzalez) reflect this.

The querstion is, should the results of GIMP be consistent with literature?

My answer to this is YES.

The act of EROSION is to produce results that have 'eroded' details, and the
image should look darker.  So GIMP should reflect that to be accurate...that is
if we want to call this operation EROSION.

I'm not nitpicking...it's the same as if we filter name "lowpass filter" but
instead produced a result of highpass filtering but we argued that the result
would be correct if we defined high frequencies to start at 0.



The result that we get is not this.

Comment 11 weskaggs 2005-06-22 17:09:44 UTC
I am going to resolve this as WONTFIX.  If we were starting from scratch, it
would probably be better to do it the other way, but the rationale is not so
strong as to justify a complete reversal of the existing behavior.
Comment 12 Raphaël Quinet 2005-06-23 16:58:16 UTC
I am sorry, but I would like to reopen this bug report.  I have no idea why the
dilate/erode filters were named "incorrectly" in the first place, but all
references that I found in books and in my old course on digital imaging at the
uni had examples where dilate == more white (assuming that the foreground pixels
are white and the background pixels are black).  The examples were given for
both 1-bit images and grayscale images.

Although this is just a matter of agreeing on what is "foreground" and what is
"background", all examples that I found in my books and in a simple google
search for dilate/erode show white as foreground and black as background.  So
I would like to re-open this bug report so that we use the "usual" meaning in
the GIMP.  All it takes is some string changes and a mention in the NEWS file.
Comment 13 Dimitri Androutsos 2005-06-23 18:53:52 UTC
Yes, I fully agree.  We should be consistent with what the definitions are for
these operations.  In general the operations of dilation and erosion were
created to work with black being 0 and white being 255.  As such, in grey scale,
the operations are based on min/max operations.

This is significant enough to warrant changing some simple strings!

Every researcher in image processing will tell you that what the GIMP does is
NOT consistent with established definitions.  
Comment 14 Raphaël Quinet 2005-06-24 13:08:44 UTC
Regarding comment #13: note that the decision to have black as 0 and white as 1
(or 255) is rather arbitrary, as I suggested in my previous comment.  However,
even when the text of the book describing dilate or erode was only talking about
foreground/background and not about specific values, the examples were using
black as 0 and white as 1.  So I think that we should follow what seems to be
the established practice.

If nobody has serious objections in the next week or so, then I will implement
the changes in CVS (including a mention in the NEWS file).
Comment 15 Sven Neumann 2005-10-20 10:46:34 UTC
Raphael, can we expect your patch anytime soon?
Comment 16 Guanglei Xiong 2006-01-08 06:01:21 UTC
The "erode and dilate" filters in Gimp are reversed to the
common sense. I try to erode a binary image in which the foreground is
white and the background is black. The resulting object is wider and
thicker than the original. The dilate filter outputs the opposite.

The typical modern imaging facilities, such as Ultrasound, MRI, CT all
output images which have white foreground and black background. So I
think Gimp should adhere this common way when dealing with mathematical
morphology.
Comment 17 Dave Neary 2006-02-16 17:47:12 UTC
Created attachment 59511 [details] [review]
Swap erode and dilate


Attached patch swaps erode and dilate. Can someone else check and commit?

Dave.
Comment 18 Sven Neumann 2006-02-17 07:26:03 UTC
This is a debatable change because it breaks backward compatibility in the PDB. But I tend to agree that it is a bug and that the proposed patch is the only reasonable way to fix it.
Comment 19 Clarence Risher 2006-04-18 09:17:26 UTC
I am not a big fan of complexity to maintain backwards compatibility, as a matter of fact I am downright against it.  But since I am flexible, I will propose an idea that I don't like but would solve the problem at hand.  What if the current PDB calls continued to function the same, and we had a set of new calls with a different name.  Then we can add a message to the old calls warning the user that their script is outdated, and new scripts can be written to use the new calls.
Comment 20 weskaggs 2006-05-19 16:33:21 UTC
With 2.4 approaching, it is now or never.  Fixed in cvs HEAD as per comment #17.

2006-05-19  Bill Skaggs  <weskaggs@primate.ucdavis.edu>

	* plug-ins/common/vpropagate.c: swap meanings of "dilate"
	and "erode"; fixes bug #156545.
Comment 21 Michael Schumacher 2006-08-03 07:33:27 UTC
*** Bug 349746 has been marked as a duplicate of this bug. ***
Comment 22 bernhard 2008-02-11 21:46:07 UTC
I'm sorry that i did not read all the comments, but as i think in gimp 2.4.4 its incorrect. if i use dilate on 2 different photos with dark areas the areas don't grow as the description says but shrink.
Comment 23 weskaggs 2008-02-11 23:37:08 UTC
Actually, if you read the comments, you will see that the bug seems to be in the description rather than the function.  Can you please clarify what description you are referring to?  (The meanings of "dilate" and "erode" were reversed as a result of this bug report -- presumably the description did not get changed appropriately when this happened.)
Comment 24 bernhard 2008-02-13 11:23:16 UTC
I refer to the tooltip that appears when you hover the filter inside the GIMP
Comment 25 weskaggs 2008-02-14 03:04:54 UTC
2008-02-13  Bill Skaggs  <weskaggs@primate.ucdavis.edu>

	* plug-ins/common/vpropagate.c:  change "darker" to "lighter"
	in blurb, in response to comment #24 in bug #156545.

Okay, fixed in trunk. Thanks for the pointer.  This probably shouldn't be backported, since it would cause problems with translations.
Comment 26 Michael Schumacher 2016-12-09 14:19:10 UTC
*** Bug 768741 has been marked as a duplicate of this bug. ***