stroke selection not antialiased
This discussion is connected to the gimp-user-list.gnome.org mailing list which is provided by the GIMP developers and not related to gimpusers.com.
This is a read-only list on gimpusers.com so this discussion thread is read-only, too.
stroke selection not antialiased | Ernie Wright | 26 Oct 19:20 |
stroke selection not antialiased | Simon Budig | 26 Oct 19:48 |
stroke selection not antialiased | Ernie Wright | 26 Oct 23:14 |
stroke selection not antialiased | Sven Neumann | 27 Oct 09:04 |
stroke selection not antialiased | Nathan Lane | 27 Oct 15:36 |
stroke selection not antialiased | Simon Budig | 27 Oct 16:32 |
stroke selection not antialiased | Ernie Wright | 28 Oct 04:49 |
stroke selection not antialiased | David Gowers | 28 Oct 08:24 |
stroke selection not antialiased | Sven Neumann | 28 Oct 08:30 |
stroke selection not antialiased | Nathan Lane | 30 Oct 19:25 |
stroke selection not antialiased | Ernie Wright | 28 Oct 04:37 |
stroke selection not antialiased
I don't get *any* antialiasing when I stroke elliptical selections.
Antialiasing is checked in the tool attributes of the Ellipse Select tool. It's also checked in the Choose Stroke Style dialog.
Fills antialias just fine. I also get an antialiased line if I convert the selection to a path and then stroke the path. See
http://home.comcast.net/~erniew/gimp_alias.png
I haven't seen this discussed anywhere, which is normally a clue that I'm doing something wrong, but I can't imagine what it might be.
Using both 2.2.10 in SUSE 10.1 and whatever GIMP version is in CentOS 5 (I believe that's also a 2.2.x version).
- Ernie http://home.comcast.net/~erniew
stroke selection not antialiased
Ernie Wright (erniew@comcast.net) wrote:
I don't get *any* antialiasing when I stroke elliptical selections.
Antialiasing is checked in the tool attributes of the Ellipse Select tool. It's also checked in the Choose Stroke Style dialog.
Fills antialias just fine. I also get an antialiased line if I convert the selection to a path and then stroke the path. See
http://home.comcast.net/~erniew/gimp_alias.png
I haven't seen this discussed anywhere, which is normally a clue that I'm doing something wrong, but I can't imagine what it might be.
You're not doing anything wrong and we know about this effect. Gimp doesn't do anything wrong either, it just does something the user does not expect it to do.
The effect is discussed in bug #50730 ( http://bugzilla.gnome.org/show_bug.cgi?id=50730 ). I played around with the code in question in 2003 (see comments #15 and #16) but did not come up with a real solution. The underlying problem is, that the selection boundary you're stroking is made up of lots of horizontal and vertical segments - the ones you see when zooming into the image and watching the marching ants.
Stroking it with the method you choose results in a lot of faithfully rendered edges, which happen to mirror the original pixels and looks like not-existing antialiasing.
Converting the selection to a path intentionally drops these little horizontal/vertical segments and approximates them with a smooth bezier curve and suddenly the whole problem disappears.
A proper fix probably would need a different approach on how we handle the selection, but this part of the discussion should happen on gimp-devel.
I hope this helps, Simon
stroke selection not antialiased
Simon Budig wrote:
Ernie Wright (erniew@comcast.net) wrote:
I don't get *any* antialiasing when I stroke elliptical selections.
You're not doing anything wrong and we know about this effect. Gimp doesn't do anything wrong either, it just does something the user does not expect it to do.
The effect is discussed in bug #50730 ( http://bugzilla.gnome.org/show_bug.cgi?id=50730 ).
Thanks Simon, very helpful. Good to know it's not just me.
(My search-fu wasn't very good. This has, in fact, come up in gimp-user several times before. My bad.)
"Does something the user does not expect" is the definition of a design flaw (which might be what you meant, irony being difficult to detect in e-mail), but as you say, that discussion probably belongs on gimp-devel.
- Ernie http://home.comcast.net/~erniew
stroke selection not antialiased
Hi,
On Sun, 2008-10-26 at 18:14 -0400, Ernie Wright wrote:
"Does something the user does not expect" is the definition of a design flaw
It's more like "technically it does the right thing, but the user expects a different result". Unfortunately there is often no clear solution for these kind of problems.
Sven
stroke selection not antialiased
So why not convert your selection to a path then stroke the path? This is a
good work around, and even in my mind now, this makes sense. The stroked
path is antialiased.
Nathan
On Mon, Oct 27, 2008 at 2:04 AM, Sven Neumann wrote:
Hi,
On Sun, 2008-10-26 at 18:14 -0400, Ernie Wright wrote:
"Does something the user does not expect" is the definition of a design flaw
It's more like "technically it does the right thing, but the user expects a different result". Unfortunately there is often no clear solution for these kind of problems.
Sven
_______________________________________________ Gimp-user mailing list
Gimp-user@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
stroke selection not antialiased
Nathan Lane (nathamberlane@gmail.com) wrote:
So why not convert your selection to a path then stroke the path? This is a good work around, and even in my mind now, this makes sense. The stroked path is antialiased.
This is a good workaround if you know what you're doing and what effect you're after. We just cannot make this descision on behalf of the user from within Gimp code.
Bye,
Simon
stroke selection not antialiased
Sven Neumann wrote:
On Sun, 2008-10-26 at 18:14 -0400, Ernie Wright wrote:
"Does something the user does not expect" is the definition of a design flaw
It's more like "technically it does the right thing, but the user expects a different result".
Design flaws aren't technical problems, they're conceptual problems. The program is doing the wrong thing correctly.
- Ernie http://home.comcast.net/~erniew
stroke selection not antialiased
Simon Budig wrote:
Nathan Lane (nathamberlane@gmail.com) wrote:
So why not convert your selection to a path then stroke the path? This is a good work around, and even in my mind now, this makes sense. The stroked path is antialiased.
This is a good workaround if you know what you're doing and what effect you're after. We just cannot make this descision on behalf of the user from within Gimp code.
I can't believe any user actually wants this behavior.
But assuming some do, they could still get it by untoggling the Antialiased checkbox in Choose Stroke Style--and in fact, I would expect users who want aliased strokes are already doing that, unaware that the Antialiased setting makes no difference at all (that I can see, anyway).
- Ernie http://home.comcast.net/~erniew
stroke selection not antialiased
On Tue, Oct 28, 2008 at 2:19 PM, Ernie Wright wrote:
Simon Budig wrote:
Nathan Lane (nathamberlane@gmail.com) wrote:
So why not convert your selection to a path then stroke the path? This is a good work around, and even in my mind now, this makes sense. The stroked path is antialiased.
This is a good workaround if you know what you're doing and what effect you're after. We just cannot make this descision on behalf of the user from within Gimp code.
I can't believe any user actually wants this behavior.
But assuming some do, they could still get it by untoggling the Antialiased checkbox in Choose Stroke Style-- and in fact, I would expect
users who want aliased strokes are already doing that, unaware that the Antialiased setting makes no difference at all (that I can see, anyway).
I can confirm this bug. If you stroke using a tool (eg paintbrush), the result is antialiased, so I don't understand why the vector stroking isn't.... Actually, it is antialiased. It's just that the antialiasing quality reduces as the stroke width increases.
David
stroke selection not antialiased
Hi,
On Tue, 2008-10-28 at 17:54 +1030, David Gowers wrote:
I can confirm this bug. If you stroke using a tool (eg paintbrush), the result is antialiased, so I don't understand why the vector stroking isn't....
Simon has actually explained this quite well already. The outline you are stroking is the selection border. Since the selection is a mask it consists of pixels. So the selection border runs along pixel edges and thus consists of only horizontal and vertical segments. Zoom in and look at the marching ants. Now if you stroke this, you get the expected result.
Stroking with the paint tool is implemented by stamping the brush in regular intervals along the path you are stroking. This eliminates the problem somewhat as the stroking does not closely follow the selection border on its way along the pixel edges.
Sven
stroke selection not antialiased
Well now that really makes sense -- that might be a good wiki addition. So I believe that this tool is working both as designed and as expected -- antialias does do its job when you fill a selection though. :) And basically it can't do it's job as a rule when you stroke a selection.
On Tue, Oct 28, 2008 at 1:30 AM, Sven Neumann wrote:
Hi,
On Tue, 2008-10-28 at 17:54 +1030, David Gowers wrote:
I can confirm this bug. If you stroke using a tool (eg paintbrush), the result is antialiased, so I don't understand why the vector stroking isn't....
Simon has actually explained this quite well already. The outline you are stroking is the selection border. Since the selection is a mask it consists of pixels. So the selection border runs along pixel edges and thus consists of only horizontal and vertical segments. Zoom in and look at the marching ants. Now if you stroke this, you get the expected result.
Stroking with the paint tool is implemented by stamping the brush in regular intervals along the path you are stroking. This eliminates the problem somewhat as the stroking does not closely follow the selection border on its way along the pixel edges.
Sven
_______________________________________________ Gimp-user mailing list
Gimp-user@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user