Hi,

Carol Spears writes:

i have been playing with many generations of TheGIMP this morning. i compared the gimp's ability to make nice strokes and i found the results to be interesting and revealing:
http://carol.gimp.org/files/stroke.png

Well, the image alone doesn't make much sense. You will also have to explain what you did to create it. A more elaborate comparison would probably be helpful.

simon is busy doing other things on the irc and such, perhaps we need a volunteer to help? raphael, you have experience with taking over projects, perhaps you have some time.

It would really help if you could restrain of adding such useless and inflamatory comments to your mails. That would allow us to actually discuss the subject w/o getting into the next flamewar. But perhaps that is what you are after?

Sven

Carol Spears (carol@gimp.org) wrote:

i have been playing with many generations of TheGIMP this morning. i compared the gimp's ability to make nice strokes and i found the results to be interesting and revealing:
http://carol.gimp.org/files/stroke.png

Interesting. I always assumed that the paintcore-based stroking has not changed. I no longer have gimp 1.2 installed so I right now cannot check why this apparently has degraded a bit.

can something be done to make stroking be at least as nice as it used to be? i was blaming libart, but it was explained to me that this was not the cause.

The primary reasons for the bad antialiasing is that the boundary of a selection contains only horizontal and vertical lines. That is the reason why the results improve dramatically when the boundary gets converted to a path and then the path gets stroked.

Details are discussed in bug #50730 http://bugzilla.gnome.org/show_bug.cgi?id=50730

What would help the stroking would be an automatic conversion of the outline to a path and then stroking this. We cannot do this right now since the selection to path functionality is implemented as a plugin and the core must not depend on a plugin. I had a deeper look at potrace (http://potrace.sf.net/) and have a stripped down version on my HD that does its job in about 2000 lines of C, which is a somehow manageable but still a lot of (sophisticated) code.

I intend to look further in this and when it turns out that this might work I want to ask the potrace author if he has any concerns about the inclusion of the algorithm into the GIMP.

However, this will take a while, especially since I'll try to avoid touching computers more complicated than my digital camera next week (vacation - whee! :)

Bye,
Simon

Hi,

Simon Budig writes:

What would help the stroking would be an automatic conversion of the outline to a path and then stroking this. We cannot do this right now since the selection to path functionality is implemented as a plugin and the core must not depend on a plugin.

The core can very well use a plug-in. It just needs to handle the case that the plug-in is not available. This can be easily checked by looking up the procedure in the PDB.

If it turns out that the potrace code would be useful for the GIMP, it should probably be included as a plug-in and not been added to the core.

Sven

Hi,

Carol Spears writes:

the upper circles were stroked with the default setting of the current stroke dialog. the lower circles were stroked with the fuzzy 7 pixel brush. the stroking with gimp-1.2 did not have a default stroke option like one finds in gimp2 so it is a simple stroking with the same 7 pixel fuzzy brush.

I cannot reproduce your brush-stroking result for gimp-2.0 then. Is that a recent version of gimp-2.0 that you've been using? Does it contain the fix for bug #147836?

Sven

Hi,

Carol Spears writes:

I cannot reproduce your brush-stroking result for gimp-2.0 then. Is that a recent version of gimp-2.0 that you've been using? Does it contain the fix for bug #147836?

i am using gimp-2.0 from debian.

is there a reason that it would be fixed in the 2.0 branch and not in the 2.1 branch?

Huh? Perhaps you should have another look at the image you posted (http://carol.gimp.org/files/stroke.png). It shows different results for gimp-2.0 and gimp-2.1. I can however not reproduce this. The results I get for stroking look basically identical in gimp-2.1, gimp-2.0 and gimp-1.2. I admit that the result isn't very satisfying but I cannot reproduce your results. My guess is that you used a different brush when creating the stroke with gimp-2.0.

The bug report I refered to should actually not affect your particular example but I asked nevertheless just to be sure what versions we are comparing here. As you could have easily found out by looking at bugzilla, the fix for #147836 is in gimp-2.0.4 and of course it is also in the HEAD branch.

Sven

Sven Neumann wrote:
> My guess is that you used a

different brush when creating the stroke with gimp-2.0.

The top two look like they were stroked with a square brush, which when applied to a circle is a pretty precise recipe for what transpired...
--Adam

Adam D. Moss (adam@gimp.org) wrote:

Sven Neumann wrote:

My guess is that you used a
different brush when creating the stroke with gimp-2.0.

The top two look like they were stroked with a square brush, which when applied to a circle is a pretty precise recipe for what transpired...

The top two were created using libart (i.e. postscript-like) stroking. Since the boundary of the selection is composed of horizontal and vertical lines, libart sees "edges" and uses the miter join style to form the shape of the edges. The net effect is - as you saw - that it looks a bit like stroking with a rectangular brush, but the effect stems from a different source.

Bye,
Simon

Carol Spears (carol@gimp.org) wrote:

well, due to the many concerns about how i made these images, there is now a whole series of pngs/xcfs in this same directory, ending with: http://carol.gimp.org/files/stroke4.png where the same selection is used in all three gimp versions.

the selection has been saved in: http://carol.gimp.org/files/stroke4.xcf and simon has made certain that i did not use (even accidentally) different brushes.

Actually I tried to explain to carol that the in some 2.0 version the brush used for stroking is not always the same that is selected in the brush dialog. Looking at stroke4.png does not convince me that carol really used the brush the thought was using (I think it is bug #150716).

simon and mitch are right now discussing changes to the paintcore which might have affected this. anyone can read this discussion here: http://carol.gimp.org/gallery/journal/gimp-2004-09-25.txt

The behaviour seems to have been introduced by the patches by Henning Makholm. It is spacing dependant and fiddeling with this avoids the artefact. I have no real clue on that code and I won't work at it - at least not for the next few days.

Bye, Simon

Hi,

"Adam D. Moss" writes:

The top two look like they were stroked with a square brush, which when applied to a circle is a pretty precise recipe for what transpired...

The top two are the result of stroking the selection outline using libart. The strange outcome is because the selection boundary is not a circle but rather a series of horizontal and vertical line segments.

Sven

Carol Spears (carol@gimp.org) wrote:

On Sat, Sep 25, 2004 at 09:26:12PM +0200, Simon Budig wrote:

Actually I tried to explain to carol that the in some 2.0 version the brush used for stroking is not always the same that is selected in the brush dialog. Looking at stroke4.png does not convince me that carol really used the brush the thought was using (I think it is bug #150716).

having been a user of gimp for several years and several versions, i have a few habits "hardcoded" into my work flow.

for these examples, i actually opened the stroke dialog, closed the stroke dialog, chose the brush from the brush dialog and then reopened the stroke dialog, just to be certain. meaning, i did not even rely on the dialog noticing that i had changed the brush.

Quoting from your IRC log:

10:40 and there is also a big difference between the brush stroking in 2.1 and in 2.0 10:42 I don't see a real difference between 2.0 and 2.1 here. 10:42 carol: maybe you've been tricked a bit by the problem that 2.0 doesn't always use the brush selected in the brush dialog for stroking. Make sure that you select the paint tool and the proper brush before stroking the selection.
10:44 (I cannot explain the different width of the stroke otherwise)

(Ok, the wording could have been clearer) [...]

10:50 nomis: not only did i make certain that i selected the proper brush before stroking. i made certain that the proper brush was selected before opening the dialog even 10:50 carol: switch to the paintbrush before stroking.

Apparently you missed that.

Bye, Simon

Hi,

Simon Budig writes:

Actually I tried to explain to carol that the in some 2.0 version the brush used for stroking is not always the same that is selected in the brush dialog. Looking at stroke4.png does not convince me that carol really used the brush the thought was using (I think it is bug #150716).

Yes, that's a nasty one. I got hit by that as well when I tried to reproduce the strokes with 2.0.4. It is fixed in 2.0.5. That doesn't mean that the stroking looks better but at least the stroking now uses the brush one thinks it would be using.

Sven