GNOME Bugzilla – Bug 156545
dilate/erode mis-named (refer to opposite operations)
Last modified: 2016-12-09 14:19:10 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.
Almost impossible to change that now. The PDB functions are there for a while and if we change the semantics, other scripts will break.
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.
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.
*** Bug 158231 has been marked as a duplicate of this bug. ***
*** Bug 168284 has been marked as a duplicate of this bug. ***
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.
I think this should be re-opened.
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.
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).
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.
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.
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.
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.
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).
Raphael, can we expect your patch anytime soon?
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.
Created attachment 59511 [details] [review] Swap erode and dilate Attached patch swaps erode and dilate. Can someone else check and commit? Dave.
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.
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.
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.
*** Bug 349746 has been marked as a duplicate of this bug. ***
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.
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.)
I refer to the tooltip that appears when you hover the filter inside the GIMP
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.
*** Bug 768741 has been marked as a duplicate of this bug. ***