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

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

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

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

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

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

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