Joao wrote:

That said, I raise the question: Should the scissors tool be visible by default in the toolbox?

Well, the real problem with it is that the edge-hugging algorithm sucks. It would be a very useful tool if it actually worked. So I suppose my attitude is:

a) It's too late in the 2.2 development cycle to make such a major change.

b) In the next cycle, it would be very nice if somebody could improve the tool's algorithm.

I looked at the code not too long ago, and my impression was that it reads like it was written by somebody who started with a complex and incomprehensible algorithm and then added kludges onto it in an attempt to get it to work. The best approach might be to clear it out and start fresh. It shouldn't be horribly difficult, since the problem of connecting two points with a curve that tries to hug edges is not really all that hard. (Finding a solution quickly when the points are far apart might be challenging, though.)

Best, -- Bill

______________ ______________ ______________ ______________ Sent via the KillerWebMail system at primate.ucdavis.edu

Hi,

"Joao S. O. Bueno Calligaris" writes:

I should've done this __very__ earlier on the dev. cycle. But the fact is that I think developers should seriopusly consider the visibility of the "scissors tool" on the tool box.

I mean - it is a good hack, it is there for historical reasons, and the graphic algorithyms behind it are nice for paper presentations and etc...

But nowadays, who seriously uses it? The fact is that it "doesn't deliver" the functionality it should, and is simply awkard. The new Vectors interface from GIMP 2.0 allows one to do with vectors what the Scissors tool should be doing, only it is easier to use, and to figure out how to use.

I used it earlier today and it fit my needs. I don't see why we should remove it only because you don't like it. Even if we came to the conclusion that it would be better to hide it, we would definitely not do this at this point of the development cycle (being in UI freeze for several weeks).

Sven

Hi,

Joao S. O. Bueno Calligaris wrote:

But nowadays, who seriously uses it?

I use it all the time to get a first rough draft when cutting out shapes. It's miles quicker than using bezier, and since selections are just masks, I convert the selection to a mask and fine-tune it afterwards. I have found that for me (low-end power user if such a thing exists) this is the way I get decent results quickest.

That said, I raise the question: Should the scissors tool be visible by default in the toolbox?

I think it is a more useful tool to beginners (and thus the target audience of defaults) than the path tool.

Cheers, Dave.

I introduce about 50 beginning students each year to the GIMP, and in my experience, this tool seems to be one of the best piquant tools for the students to use. If anyting, I'd make it easier to undo the last point added and make it easier to close the curve when done, but please don't remove the tool from its default place in the toolbox.

_-T

_________________

On 06.12.2004, at 19:44, Joao S. O. Bueno Calligaris wrote:

But nowadays, who seriously uses it?

I do. It's not very useful to mask an object in a low contrast environment but it works perfectly well for instance to mask an digitally photographed object against a somewhat distant background to only modify the background some more (reduce color intensity, blur, etc.) to strengthen the effect of the photo.

Servus, Daniel

On Tue, 2004-12-07 at 08:38 +0000, shaneyfelt@juno.com wrote:

I introduce about 50 beginning students each year to the GIMP, and in my experience, this tool seems to be one of the best piquant tools for the students to use.

I second that.

If anyting, I'd make it easier to undo the last point added and make it easier to close the curve when done

+1

Hi,

Tomas Mraz wrote:

If anyting, I'd make it easier to undo the last point added and make it easier to close the curve when done

+1

And that annoying bug where you can't have anchor points within 8 pixels of the left or top edges (and possible the other edge too).

I am sure I've seen it in CVS, but can't find it right now. Am I imagining things?

A hint for closing the curve - you can zoom in and out with + and - while editing a curve, which is handy for getting those clicks right if there are a number of points (or if you miss the first time). Also very handy for adding points or dragging anchors when the curve is closed.

Cheers,
Dave.

-----Original Message-----
From: gimp-developer-bounces@lists.xcf.berkeley.edu [mailto:gimp- developer-bounces@lists.xcf.berkeley.edu] On Behalf Of William Skaggs Sent: 06 December 2004 19:05
To: gimp-developer@lists.xcf.berkeley.edu; Joao S. O. Bueno Calligaris Subject: Re: [Gimp-developer] Scissors tool

[...]

I looked at the code not too long ago, and my impression was that it reads like it was written by somebody who started with a complex and incomprehensible algorithm and then added kludges onto it in an attempt to get it to work. The best approach might be to clear it out and start fresh. It shouldn't be horribly difficult, since the problem of connecting two points with a curve that tries to hug edges is not really all that hard. (Finding a solution quickly when the points are far apart might be challenging, though.)

I think I was probably the last person to do any major work on the scissors tool, and that was in 1999 to port it to the (then new) tile-based world.

The code when I took it on was a "software Vietnam"; a complete mess. I had to read the SIGGRAPH paper it was attempting to implement before I could fix it, and believe me it left my hands much cleaner than I got it!

There are two areas where it could do with improvement: - it doesn't handle tile-boundaries (it treats them as edges) - the point editing interface sucks; I merely made the existing one work but it might be interesting to see if it could use the same code from the Path tool (that was always the plan)

Austin

Austin Donnelly (austin@gimp.org) wrote: [scissors tool]

I think I was probably the last person to do any major work on the scissors tool, and that was in 1999 to port it to the (then new) tile-based world.

The code when I took it on was a "software Vietnam"; a complete mess. I had to read the SIGGRAPH paper it was attempting to implement before I could fix it, and believe me it left my hands much cleaner than I got it!

There are two areas where it could do with improvement: - it doesn't handle tile-boundaries (it treats them as edges)

I am not sure if that is really the case. I some time ago looked at the code and I believe that the broken behaviour for areas of very similiar colors (i.e. preferring multiple of 45° lines instead of straight lines between control points) is not correlated to tile boundaries and stems from the fact, that the algorithm moves "pixel by pixel" without taking the deviation from the straight line into account.

IIRC (been a time and the code definitely is nontrivial) the paper specifies a function $f_D$ to have high costs for sharp changes in boundary detection and I don't remember seeing an equivalent of this in the code (might very well have missed it though).

Sorry for not being more specific about that.

- the point editing interface sucks; I merely made the existing one work but it might be interesting to see if it could use the same code from the Path tool (that was always the plan)

That'd indeed rock. Intelligend Scissors could just be a path tool that has a very crude way to calculate the segment between two control points. The API might already support this (you can have custom stroke types) but details would be needed to work this out (we'd then have a dependency between the path and the associated drawable, since the path needs the drawable to figure out its outline).

Bye, Simon

On Wed, 8 Dec 2004 14:31:10 +0100, Simon Budig wrote:

Austin Donnelly (austin@gimp.org) wrote: [scissors tool]

- the point editing interface sucks; I merely made the existing one work but it might be interesting to see if it could use the same code from the Path tool (that was always the plan)

That'd indeed rock. Intelligend Scissors could just be a path tool that has a very crude way to calculate the segment between two control points. The API might already support this (you can have custom stroke types) but details would be needed to work this out (we'd then have a dependency between the path and the associated drawable, since the path needs the drawable to figure out its outline).

This is a side issue, but for the intelligent scissors there is another feature that I thought about: adjusting the position of a selected control point automatically within a small radius (e.g., 5 pixels), based on the closest bits of the calculated segments attached to that point.

Sometimes when I use the IScissors and I forget to zoom in to add some control points precisely, I end up with a control point that is a few pixels off of the edge that I want to select. The calculated segments are then hugging the shape quite closely except for the pixels close to the misplaced control point (i.e., there is a little bit that sticks out of the shape).

Although being able to move the control points as in the Path tool would already solve most of the problem, it could be interesting to have an option to re-position a selected control point automatically. This has a rather low priority: it is just a "nice to have" thing.

-Raphaël

quinet@gamers.org (2004-12-08 at 1714.59 +0100):

That'd indeed rock. Intelligend Scissors could just be a path tool that has a very crude way to calculate the segment between two control points. The API might already support this (you can have custom stroke types) but details would be needed to work this out (we'd then have a dependency between the path and the associated drawable, since the path needs the drawable to figure out its outline).

This is a side issue, but for the intelligent scissors there is another feature that I thought about: adjusting the position of a selected control point automatically within a small radius (e.g., 5 pixels), based on the closest bits of the calculated segments attached to that point.

Sometimes when I use the IScissors and I forget to zoom in to add some control points precisely, I end up with a control point that is a few pixels off of the edge that I want to select. The calculated segments are then hugging the shape quite closely except for the pixels close to the misplaced control point (i.e., there is a little bit that sticks out of the shape).

Although being able to move the control points as in the Path tool would already solve most of the problem, it could be interesting to have an option to re-position a selected control point automatically. This has a rather low priority: it is just a "nice to have" thing.

Sorry, I do not understand exactly what you mean, but in 1.2 you were able to move points, and it would readjust the lines that join them. A different issue is when it stubbornly wanted to put a point somewhere and you moved the mouse a lot but the dot would automatically go to the place you do not want, and the lines still follow a wrong path. You could also add points too, the interface sucked, yes, and due the tile problem it seems to do whatever it wants sometimes, but the poor tool was a bit more than everyone experimented with 30 secs of play.

Of course, in past years the algoritms have evolved, see for example the concept of freehand sketch selection: http://vision.ai.uiuc.edu/~tankh/Selection/selection.html

GSR

GSR - FR wrote:

Of course, in past years the algoritms have evolved, see for example the concept of freehand sketch selection: http://vision.ai.uiuc.edu/~tankh/Selection/selection.html

This is the second time I have seen something which really only exist as a research paper but would be really nice to have as a GIMP plug-in. I wonder if there is enough information in the PDF files to allow the creation of a plug-in to implement the algorithm described. The other paper was related to some impressive noise reduction in images.

On Tue, 07 Dec 2004 09:46:29 +0100, Sven Neumann wrote:

Hi,

Laxminarayan Kamath writes:

On Mon, 06 Dec 2004 21:45:36 +0100, Sven Neumann wrote:

Hi,
I used it earlier today and it fit my needs. I don't see why we should remove it only because you don't like it. Even if we came to the conclusion that it would be better to hide it,............ Sven

Are threre any poll engines you would like to use?

OK, two things:

(1) Your question doesn't make any sense to me. (2) Please don't send me private emails but stick with the mailing-lists.

Sven

OOps, Sorry Sven, Gmail is nice but is confusing for replies. Will be care full next time.
By the way, what i mean is, when such confusions occur, like whether or not to remove a tool from the toolbar, isn't it nice to have a poll engine and make the poll public?

Hi,

Laxminarayan Kamath writes:

By the way, what i mean is, when such confusions occur, like whether or not to remove a tool from the toolbar, isn't it nice to have a poll engine and make the poll public?

No, I don't think such questions should be decided by means of a poll. This is GIMP development, not some kind of democracy ;)

Sven

On Thu, 9 Dec 2004 09:27:02 -0200, Joao S. O. Bueno Calligaris wrote:

On Thursday 09 December 2004 06:45, Laxminarayan Kamath wrote:

OOps, Sorry Sven, Gmail is nice but is confusing for replies. Will be care full next time.
By the way, what i mean is, when such confusions occur, like whether or not to remove a tool from the toolbar, isn't it nice to have a poll engine and make the poll public?

You are worrying over the edge here. There is no chance this tool will be removed - not this time, nor soon.

What happened is that I, having the opinion that the tool is borken, sent a question about it to the list - which is public, in some sense. People replied that not only it is actually usable, but they use it on an often basis.

Therefore, there is no sense in hiding it. And just one more point: I never suggested the removal of the tool, but just hiding the tool - it would be available from dialogs->tools, even to be put back into the toolbox.

If a change is made to the GIMP that you do not like - in a way it brakes the way you work, Bugzilla is the place to ask for the old behavior back.

Recently, for example, there was a bug asking for the old behavior of the Move tool - that would change the selected layer. That was promptly implemented as an option.

Regards.

JS ->

Yeah I now agree. In poll, you only understand the overall view,not what the user/developer really wants. The poll idea was *bullshit*. unless it extends way beyond radio buttons. which comes back to the idea of mailing lists ;)