GNOME Bugzilla – Bug 50730
Stroking a selection should have better anti-aliasing
Last modified: 2018-05-24 10:30:09 UTC
The Antialiasing of GIMP in general is not good enough not smooth enough. Compare a selection and the shape of the selection with PS you will recognize that the GIMP produces more stairy effects MUCH MORE. Escpecially with the Stroke Funtkion you only get a very stairy Line. So you cannot create perfect shapes to get for example a good 3D Interface, because if you use Lighting Effect on a channel which has stairy shapes you get SHIT not a smooth or good 3D looking shape. I think this is very important because what are all these wonderfull Plug ins for when i even cannot create perfect shapes without any stairy effect. Please improve this in GIMP 1.4 or 2.0. Thanks i would be gratefull to get a better Antialiasing also in the FONT implention. Greets Waldgeist
Re-assigning all Gimp bugs to default component owner (Gimp bugs list)
Reassing to current CVS since this is a wish item and will not be fixed in the 1.2 tree. You should try the gimp-freetye plug-in (http://freetype.gimp.org/) to get a glimpse on the font renderer we want to use for Gimp-1.4.
I really think that this needs to be fixed too... it really hurts gimp's viability for making web graphics. Everyone whom I've shown GIMP to has complained about this. The line anti-aliasing problem shows up on selections, strokes, etc. We really need better selection smoothing - a 'smooth selection' option like in photoshop would be great too. GIMP is wonderful, but this problem holds it back in a lot of places; it'd be nice to see it improved. On the subject of feature enhancements - maybe someone could hook a little survey form up on gimp.org that'll let people prioritize particular new features. :) Thanks a bunch, Mathew Johnston
I too believe this is a very serious issue. Especially with selections. Somebody should check out the antigrain geometry library at http://www.antigrain.com/ and the way to integrate it with Gimp. It's supposed to be even better than photoshop (they have some pics there). Although it isn't GPL it seems to be a very flexible license. The new font support looks amazing, I'll probably post a wish with text layers support. (gimp developers will say, when are they going to have enough?) :-D Regards, Andrés
There are several issues mentioned in the original bug report and in the two comments above: 1) The selections are not smooth enough 2) Stroking the selections does not give good results (stairy effect) 3) The text tool has bad anti-aliasing 4) Add a survey form on www.gimp.org for prioritizing the new features 5) Integrate the antigrain library in the GIMP. These should have been posted in separate bug reports because each bug report must address only one specific issue. But in this case, I think that all points except for the second one will be solved soon or are irrelevant: 1) I think that this point is not relevant, unless you can show some specific examples of selections that are not smooth enough when you fill them a color or when you perform some operation on them (other than stroking). Note that the selections are sometimes smoother than what is displayed by the selection outline (the outline uses a threshold). So in order to check if a selection is smooth or not, you should fill it with a color and see what happens. There is also the option Selection->Feather if you want a smoother selection than what you currently have. 2) The Stroke option could be improved because it does not give good results with thin brushes. This problem is similar to the problem that we have when drawing straight lines (shift-click) with a small brush. 3) The text tool will be much better in GIMP 1.4. 4) I don't think that adding a survey form on www.gimp.org would be a good idea. Keep in mind that a feature will only be added if there is someone who volunteers for working on it. So if none of the existing developers has enough spare time to work on a new feature and if nobody else contributes a patch for implementing it, then it is not likely that the feature will be added soon. Getting more requests for some feature will not get it implemented faster, unless someone is ready to work on it. Anyway, if you want a survey for GIMP features, you could check some other GIMP-related sites. For example, the GIMP User Group (http://gug.sunsite.dk/) has a survey form on their home page. 5) I don't know much about the antigrain library and their web site does not seem to work for the moment. In any case, if their license is not GPL or GPL-compatible, it is not likely that it would be integrated into the GIMP. So we are mostly left with point (2) in this bug report. If not, then please open a separate bug report because I do not want to address the other issues in this one.
Point (2) is basically bug #69773. This has recently been addressed in the unstable branch: 2002-06-12 Sven Neumann <sven@gimp.org> * app/paint/gimppaintcore.[ch]: applied a patch from Henning Makholm <henning@makholm.net> that vastly improves drawing of thin lines. See bug #69773 for a detailed description.
The problem is not quite fixed by the #69773 thin-lines patch. Apparently, when a selection is stroked, there's a piece of code sitting somwhere which tries to convert the selection outline to a polygon; then that polygon's edges is sent to the line interpolator in the paintcore. Even though the paintcore's line code is now able to draw nice anti-aliased lines, what it actually is asked to draw by the polygonalizer is a series of axis-parallel integral lines: one pixel right, then one pixel down, then two pixels right, then another pixel down, and so forth. (This sequence of line segments seems to be identical to the thresheld polygon along which the ants march when the image is zoomed.) This means that ugly staircases are still seen. This also gives rise to another bug: When one strokes, say, a large circular selection with a 3x3 fuzzy brush and spacing 200%, the dots along the 45 degree parts of the circle are visibly closer than the dots along the horizontal/vertical parts of it. This is because the distance between brush position is measured along the staircase outline. What's needed to fix both of these effects is a smarter selection-to-polygon algorithm. Alas, my ideas about how such a beast could work are extremely foggy.
Since we already use Libart for scan-conversion (see app/core/gimpscanconvert.c) we should also consider to use the sophisticated algorithms it offers for computation of stroke paths and antialiased rendering of vector paths.
I've looked a libart now, and as far as I can tell, it doesn't have what we need here, namely code that goes FROM the pixel-based selection TO the vector description of nice smooth polygonal outline that approximates the pixels (which can then be fed to the paintcore). Libart seems to be all about vector-to-vector or vector-to-pixels, not the other way around. It does have a set of functions for doing "strokes", but those are vector-to-vector operations whose name refers to the "stroke" primitive in PostScript, which is something quite different from what the Gimp calls stroking a selection. Did I miss something somewhere?
This is the license of the antigrain library. I think that is pretty much gpl-compliant. Permission to copy, use, modify, sell and distribute this software is granted provided this copyright notice appears in all copies. This software is provided "as is" without express or implied warranty, and with no claim as to its suitability for any purpose. I would love to actually code this myself but my skills are not good enough for a project like gimp. Especially since this involves dealing with C++ code (for the antigrain library). And Raphael, try to go easy on users because your response was somewhat harsh. The page of the library is antigrain.com and the sample screenshot comparing Photoshop/Xara antialias method to antigrain's can be found at http://www.antigrain.com/img/compare_to_xara.gif I hope you guys can integrate this thing. I'd really like to get my sister to switch from Photoshop :-D
I tried to work with the GIMP one month ago instead of Photoshop and I miss the stroke function from Photoshop. The best result I could find is to use the freetype tool to create Bezier curves from my Text and then to stroke it. But even like that, the result is very fair compared to Photoshop. I think it would be very important to improve this function in 1.4 or 2.0 version because this is a very useful function and it is currently impossible to get professional results in GIMP.
Bumping a bunch of enhancement requests which will not be done by the feature freeze to Future. Dave.
Oh, forgot to update that bug. Sorry. I have checked in some experimental code a month ago, that improves the stroking code. A new function applies a modified version of the Douglas-Peucker algorithm to the polygon that describes the selection outline. The results are better now (IMHO). Please note, that this does not make an elliptical selection result in a perfectly stroked ellipse. But I think this would be overkill. Please try if the new behaviour is better and add comments to this bug.
If the new code is what is in 1.3.21 [I was eager to try this out and just grabbed the latest Debian package], then it's an obvious improvement relative to what I saw in June 2002. The diagonal-spacing problems are gone; see example on <http://henning.makholm.net/misc/beads.png>. However, the accuracy of the outline tracing is somewhat lacking. See <http://henning.makholm.net/misc/bullet.png> where I first poured red paint through an elliptical selection and then stroked the outline with a 1x1 pixel black brush (the postscript-like stroking options gave the same result). At places around the outline there are visible splotches of red outside the black line and white inside it. It might be possible to fix this by tuning the tolerance distance parameter in the Douglas-Peucker algorithm, but the stroke style dialog does not provide a user interface for that. (I will try to get time soon to play with a cvs checkout and try out some ideas I have for optimizing Douglas-Peucker for thin antialised lines).
Yes, 1.3.21 contains these changes. The code lives in app/base/boundary.c, simplify_boundary(). Please look at it and try to improve it. There are two problems with the further improvements: a) the coordinates for the boundary points are integers b) the threshold for no further subdivisions has to be big, because 45 degree pixel-stairs have to be caught - otherwise the libart ("postscript") stroking fails badly. The modification I applied to Douglas-Peucker is, that the subdivision always happens in the middle of the coordinate set. (Original Douglas Peucker picks the point with the greatest distance to the line). There are some cases where this leads to better results. I'd be happy if you manage to find some time to improve these heuristics.
I disabled the use of the simplify_boundary function for now, since quite some people were confused and the traditional behaviour fails in a more predictable way... :-/ 2003-12-31 Simon Budig <simon@gimp.org> * app/core/gimpdrawable-stroke.c * app/paint/gimppaintcore-stroke.c: Don't simplify the border of the selection. Quite some people were confused by the polygonal look of a stroked ellipse. The old behaviour doesn't look good, but the new one isn't really better. Since the old behaviour is more predictable, I am reverting this for now (Please note that the function to simplify the boundary still is available, it just is unused). Hopefully at some point it will be possible to have non-integer boundary coordinates or even a more sophisticated set of "vector-selection" tools.
Maybe this is now fixed with the patch in bug 147836?
The description of bug 147836 does not suggest so, at least. The present bug is that no matter how nicely anti-aliased the selection is (which is what 147836 addresses in the special case of epllipses), the stroke tool will (in effect) apply a brute-force threshold filter to the selection channel and then stroke the pixel-for-pixel outline of the resulting 1-bit image. By construction, this outline always consists of little axis-parallel pieces, which (a) makes thin strokes look ugly and (b) screws up the distance calculation for stroking with large brush spacings.
I agree that the anti aliasing could be improved in GIMP not only strocking but with the magic wand tool. The results seen in Photoshop are much better that those obtained in GIMP, I can provide examples.
This bug report is useless as it stands. What we need here are reproducable examples with detailed description on the expected behaviour. I am closing the report as INCOMPLETE and ask people to open more useful bug reports if they feel capable of providing the necessary information with it.
Actually I don't think that this bug is as useless as you make it sound. The bad effects of stroking the boundary of a selection are immediately visible when you use e.g. libart stroking on an e.g. elliptical selection and compare it to the antialiasing of stroking a path. The latter is the desired outcome. The fact that we have no idea how to fix this is not a good reason to close this report. The discussion we had here is IMO important and should stay visible. Reopening.
*** Bug 157521 has been marked as a duplicate of this bug. ***
*** Bug 152846 has been marked as a duplicate of this bug. ***
Eeek.. this is getting out of control :-) Just got to mails from 2 different people complaining about this very issue. [GUG] question, re: elliptical outline Date: Today 21:09:48 From: Matt Cahill <m-cahill@rogers.com> Re: [Gimp-user] circles and circumferences... again Date: Today 18:31:59 From: Thadeu Penna <tjpp@terra.com.br> To: <gimp-user@lists.xcf.berkeley.edu>
It is still not fixable. Perhaps you should tell those people to stroke a path instead. For 2.4 we should add a Shapes tool to fix this issue.
*** Bug 163881 has been marked as a duplicate of this bug. ***
*** Bug 321457 has been marked as a duplicate of this bug. ***
*** Bug 704304 has been marked as a duplicate of this bug. ***
As mentioned in bug 704304, using an odd stroke width looks almost like antialiasing.
Created attachment 249328 [details] Antialiasing issue when stroking a selection This picture shows that Antialiasing is a proper option when stroking a selection, which works when width is an odd number, but does not work when width of line is an even number.
Hello Michael Natterer, "What you are seeing is not antialiasing, you are seeing half pixels being filled. This is not antialiasing but just a blurry outline." In bug 704304, you assume that I think Antialiasing when stroking a selection is a side effect. But it's not, it's part of the options of the dialog box that appears. So either it's a really crappy side effect that appears half of the time, and that should be corrected and no option should appear, or it's a real feature that works only half of the time.
Antialiasing only does something when you are filling partial pixels, in the case of an even stroke width this never happens, thus the antialiasing toggle has no effect. For odd widths, that is of course antialiasing in effect, not some weird side effect, I was wrong there.
*** Bug 755338 has been marked as a duplicate of this bug. ***
*** Bug 768342 has been marked as a duplicate of this bug. ***
*** Bug 777801 has been marked as a duplicate of this bug. ***
*** Bug 781124 has been marked as a duplicate of this bug. ***
Apparently using join style "round" is a workaround for getting some antialiasing anyway, see bug 781124.
-- 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/6.