Philip L. (deathpudding@gmail.com) wrote:

I'm considering creating a new brush system for the GIMP as part of the Summer of Code in order to make GIMP more suitable to digital painting. I've made some contributions to the project before, but it has been a while. Can anyone comment on how extensive changes to the rest of the codebase would need to be, how this would be affected by the future incorporation of GEGL, and whether this could be completed in the allotted time?

It is not exactly clear to me what you mean by "how extensive changes to the rest of the codebase would need to be" - this seems to me to be very much up to you and your ideas for the brush system enhancements.

As for GEGL, I believe in your case it is pretty safe to ignore GEGL for now and just work on the current model. You should keep your code that generates the images that get pasted on the layer as generic as possible, so that it can be changed to different pixel data representations later (16-bit, floats, maybe other color models etc.)

Does this help?

Bye, Simon

I'm considering creating a new brush system for the GIMP as part of the Summer of Code in order to make GIMP more suitable to digital painting.

Adding new painting tools that use a different type of brush is definitely a realistic project for somebody with your knowledge and abilities (as I remember from your previous contributions), and I bet a proposal to do that would be very well received. I don't think new tool code would interact all that strongly with GEGL. So, please sign up -- the deadline is fast approaching.

-- Bill

______________ ______________ ______________ ______________ Sent via the CNPRC Email system at primate.ucdavis.edu

Hi,
weskaggs@primate.ucdavis.edu (2006-05-07 at 1520.30 -0700):

I'm considering creating a new brush system for the GIMP as part of the Summer of Code in order to make GIMP more suitable to digital painting.

Adding new painting tools that use a different type of brush is definitely a realistic project for somebody with your knowledge and abilities (as I remember from your previous contributions), and I bet a proposal to do that would be very well received. I don't think new tool code would interact all that strongly with GEGL. So, please sign up -- the deadline is fast approaching.

New tools? Why not improving the basic brush system (sometimes with artificial limits, see animated brushes workflow or pixmap scaling) and let all tools make use of it? Erase, airbrush and so on...

GSR

New tools? Why not improving the basic brush system (sometimes with artificial limits, see animated brushes workflow or pixmap scaling) and let all tools make use of it? Erase, airbrush and so on...

To refresh people's memory, Philip is the person who wrote the code that lets the transform tools preview inside the image, along with a number of other fancy things. He doesn't even really need mentoring -- but if the SoC program could give him enough support to let him devote his summer to GIMP coding, I think that would be a good thing. (It is also compatible with the SoC rules, as long as he is a student.)

-- Bill

______________ ______________ ______________ ______________ Sent via the CNPRC Email system at primate.ucdavis.edu

Hi,
weskaggs@primate.ucdavis.edu (2006-05-07 at 1754.05 -0700):

New tools? Why not improving the basic brush system (sometimes with artificial limits, see animated brushes workflow or pixmap scaling) and let all tools make use of it? Erase, airbrush and so on...

To refresh people's memory, Philip is the person who wrote the code that lets the transform tools preview inside the image, along with a number of other fancy things. He doesn't even really need mentoring -- but if the SoC program could give him enough support to let him devote his summer to GIMP coding, I think that would be a good thing. (It is also compatible with the SoC rules, as long as he is a student.)

You refreshed my memory and confused my mind, as I am just pointing that new tools sound silly, when a more general brush system seems the solution. Take ink tool, I think it could have been done by just set the brush tip to react to things like speed and angle, and any tool would benefit, be paint or erase or whatever. So no idea how my phrases could trigger your comment or why you quoted them. ?:-|

GSR

GSR - FR wrote:

I am just pointing that new tools sound silly, when a more general brush system seems the solution. Take ink tool, I think it could have been done by just set the brush tip to react to things like speed and angle,

The ink tool is actually a good example, because it works in a completely different way than any of the Paintbrush tools -- it uses an array of interacting "ink blobs", rather than just brush marks. Possibly it could be imitated by making brushes fancier, but the tool you get that way would be completely different from the current ink tool at the algorithm level.

But the important point I was trying to make, which I will repeat, is that I think we should encourage Philip to apply without worrying too much at this moment about the exact details of his plans -- there is plenty of time to talk that over later.

Also, I only quoted you in order to establish context, and if it sounded bad, that was completely unintentional.

-- Bill

______________ ______________ ______________ ______________ Sent via the CNPRC Email system at primate.ucdavis.edu

On 5/8/06, Simon Budig wrote:

Philip L. (deathpudding@gmail.com) wrote:

I'm considering creating a new brush system for the GIMP as part of the Summer of Code in order to make GIMP more suitable to digital painting. I've made some contributions to the project before, but it has been a while. Can anyone comment on how extensive changes to the rest of the codebase would need to be, how this would be affected by the future incorporation of GEGL

As for GEGL, I believe in your case it is pretty safe to ignore GEGL for now and just work on the current model. You should keep your code that generates the images that get pasted on the layer as generic as possible, so that it can be changed to different pixel data representations later (16-bit, floats, maybe other color models etc.)

When it comes to GEGL integration and a new paint core there has been done some experiments in horizon [1]. Horizon was written with the intent to be ported to GEGL, the way the airbrush and clone tool (actually a cloning airbrush) was migrated to GEGL was that the core operation of the brush,

stamp_brush (drawable, x, y, radius, opacity, hardness, color)

was devised in such a way that it could be done as an (in-place ) operation in a processing graph. Having seperated out the processing in this way adding 16bpp / floating point support to horizon would only need changes to the logic in the GEGL op and not in the code calling it.

The GEGLification of horizon made the application too slow for it's primary platform, the Nokia 770. The overhead is constant and will be less of a problem on the desktop.

Another change that I hoped to achieve in horizon to see it's effect on a painting core was the ability to record coordinates and thus "replay" strokes. I never got quite around to this, but it allows for more interesting changes and smoothing of the strokes. The problem with such changes is that it adds even more overhead to the part of a painting application that needs to be as responsive as possible.

1: http://pippin.gimp.org/horizon/

/Øyvind K.

-- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ http://ffii.org/

Philip L. wrote:

I'm considering creating a new brush system for the GIMP as part of the Summer of Code in order to make GIMP more suitable to digital painting. I've made some contributions to the project before, but it has been a while. Can anyone comment on how extensive changes to the rest of the codebase would need to be, how this would be affected by the future incorporation of GEGL, and whether this could be completed in the allotted time?

I tried to do the same, but it is too complicated for me. As I see the problem, maybe creation of interface that allows load procedural brushes as plug-ins is good idea? Anyway, maybe it isn't the best solution, for I don't understand Gimp well.

Hi,
weskaggs@primate.ucdavis.edu (2006-05-07 at 1944.23 -0700): [Some quoting reorg]

But the important point I was trying to make, which I will repeat, is that I think we should encourage Philip to apply without worrying too much at this moment about the exact details of his plans -- there is plenty of time to talk that over later.

That I agree, if someone is already "known", allowing vagueness about the details makes sense if that means he can get in and then polish the idea in first couple of weeks and have a nice addition at the end of summer.

Also, I only quoted you in order to establish context, and if it sounded bad, that was completely unintentional.

I am used that in those cases the reply goes to the original or to own mail ("sorry to reply to myself, but I forgot a note..."), not to third party and with quoting. Now it is clear.

[Back to the unified paint tools system]

GSR - FR wrote:

I am just pointing that new tools sound silly, when a more general brush system seems the solution. Take ink tool, I think it could have been done by just set the brush tip to react to things like speed and angle,

The ink tool is actually a good example, because it works in a completely different way than any of the Paintbrush tools -- it uses an array of interacting "ink blobs", rather than just brush

Well, see it the other way around, implement the others like the ink tool, and also make ink tool have fade and gradient features ("dumb" tools have it... fade makes a lot of sense for ink tool, btw, but does not have it). I did a quick look at the code and I read it as doing polygons from one place to another. Other tools could do smarter "stamping" and get similar results (reminds me some 3d apps doing perfect looking surfaces like spheres, via triangles, while others use triangles too but fail miserably and paint polygonal "spheres").

Or add airbrush feature to eraser... the point I was trying to make is that there are multiple tools, each with separate controls, while a unified system that allows creating tools, real or imaginary, by mixing those controls seems nicer. Yeah, some will still require a different system, but others not.

marks. Possibly it could be imitated by making brushes fancier, but the tool you get that way would be completely different from the current ink tool at the algorithm level.

I do not care about the algorithm, it can be particle simulation, old demo scene tricks or pixies dancing around, what in the end matters is the results and the flexibility of the system to get even fancier results without having to fall back to tricks (airbrush erasing can be done via masks, ie, but there is not airbrush clone, is there?).

GSR

Philip L. (deathpudding@gmail.com) wrote:

You've given me another idea, though. Perhaps the path tool could be extended so that each node in a path could be a 'keyframe' in the stroke, holding brush parameters at that point. This would certainly make path stroking more powerful. On top of that, there could be a way to record a brush stroke into a path approximation, also holding brush parameters as measured during the stroke. It could then be edited and 'replayed' as desired.

Actually the vector objects already store GimpCoords at the control points and hopefully the code already interpolates them properly. This is all totally untested though, since there is no real way to control the additional parameters (pressure, xtilt, ytilt, angle).

Bye, Simon

Hi,
simon@budig.de (2006-05-09 at 0245.34 +0200):

Actually the vector objects already store GimpCoords at the control points and hopefully the code already interpolates them properly. This is all totally untested though, since there is no real way to control the additional parameters (pressure, xtilt, ytilt, angle).

That reminds me another parameter, velocity (or time delta, it is related) and that airbrush had issues with high speed... anybody knows the exact definition and use of gimp_paint_core_paint's guint32 time (I traced to http://developer.gimp.org/api/2.0/app/GimpPaintCore.html but says nothing)?

GSR

On Monday 08 May 2006 10:51 pm, GSR - FR wrote:

Hi,

simon@budig.de (2006-05-09 at 0245.34 +0200):

Actually the vector objects already store GimpCoords at the control points and hopefully the code already interpolates them properly. This is all totally untested though, since there is no real way to control the additional parameters (pressure, xtilt, ytilt, angle).

That reminds me another parameter, velocity (or time delta, it is related) and that airbrush had issues with high speed... anybody knows the exact definition and use of gimp_paint_core_paint's guint32 time (I traced to
http://developer.gimp.org/api/2.0/app/GimpPaintCore.html but says nothing)?

I tried to fiddle with it once (implementing speed as a way to select the frame of animated brushes), and got mostly lost myself. All I know is that the ink tool has a different implementation that does "time smoothing" or something to interpolate the gtk+ event time.

GSR

Joao S. O. Bueno Calligaris wrote:

On Monday 08 May 2006 10:51 pm, GSR - FR wrote:

That reminds me another parameter, velocity (or time delta, it is related) and that airbrush had issues with high speed... anybody knows the exact definition and use of gimp_paint_core_paint's guint32 time (I traced to
http://developer.gimp.org/api/2.0/app/GimpPaintCore.html but says nothing)?

I tried to fiddle with it once (implementing speed as a way to select the frame of animated brushes), and got mostly lost myself. All I know is that the ink tool has a different implementation that does "time smoothing" or something to interpolate the gtk+ event time.

The ink tool uses velocity to (optionally) add pressure attenuation according to velocity, e.g. faster strokes are thinner, which was the most interesting interpretation of velocity according to the #gimp resident artist.

This was particularly interesting for mouse or dumb-tablet users without pressure-input devices to achieve organic strokes. It was discovered that X (and thus GDK) timestamps on these events had awful resolution, hence the timestamp filtering mechanism. I don't think that any other brushes at the time were velocity- sensitive (are they now?), hence the private implementation.

Regards, --adam

Hi,
adam@gimp.org (2006-05-09 at 1654.44 +0100):

Joao S. O. Bueno Calligaris wrote:

On Monday 08 May 2006 10:51 pm, GSR - FR wrote:

That reminds me another parameter, velocity (or time delta, it is related) and that airbrush had issues with high speed... anybody knows the exact definition and use of gimp_paint_core_paint's guint32 time (I traced to
http://developer.gimp.org/api/2.0/app/GimpPaintCore.html but says nothing)?

I tried to fiddle with it once (implementing speed as a way to select the frame of animated brushes), and got mostly lost myself. All I know is that the ink tool has a different implementation that does "time smoothing" or something to interpolate the gtk+ event time.

[...]

I don't think that any other brushes at the time were velocity- sensitive (are they now?), hence the private implementation.

Animated brushes can be saved with such config... but it does nothing as it is not implemented publicly, so I guess anybody that tries the setting just gives up and saves with any of the other options from the drop downs.

The other use case for using the time is the airbrush. I looked at it time ago and looked again due this thread, first idea was checking the remaining of airbrush timer, but there seems to be none (yet?). It is required as airbrush stamps every X time, but if you move faster, the effect of time is ignored, getting stronger stampings than what really should happen.

So no, there is no current use of velocity, but just cos it is not implemented, and thus nobody thinks about possible uses. Sounds a bit recursive. ;]

GSR

GSR - FR wrote:

Animated brushes can be saved with such config... but it does nothing as it is not implemented publicly, so I guess anybody that tries the setting just gives up and saves with any of the other options from the drop downs.

It hasn't been in a stable release yet, but it is in GIMP 2.3 since 2006-01-31:

http://bugzilla.gnome.org/show_bug.cgi?id=150227

HTH, Michael

On Tuesday 09 May 2006 01:52 pm, GSR - FR wrote:

Hi,

adam@gimp.org (2006-05-09 at 1654.44 +0100):

Joao S. O. Bueno Calligaris wrote:

On Monday 08 May 2006 10:51 pm, GSR - FR wrote:

That reminds me another parameter, velocity (or time delta, it is related) and that airbrush had issues with high speed... anybody knows the exact definition and use of gimp_paint_core_paint's guint32 time (I traced to http://developer.gimp.org/api/2.0/app/GimpPaintCore.html but says nothing)?

I tried to fiddle with it once (implementing speed as a way to select the frame of animated brushes), and got mostly lost myself. All I know is that the ink tool has a different implementation that does "time smoothing" or something to interpolate the gtk+ event time.

[...]

I don't think that any other brushes at the time were velocity- sensitive (are they now?), hence the private implementation.

Animated brushes can be saved with such config... but it does nothing as it is not implemented publicly, so I guess anybody that tries the setting just gives up and saves with any of the other options from the drop downs.

Hmm.it does now - the patcjh for it has been comited some months ago - but, it doe slittle- not very usefull without a callibration curve and a way to smooth down the time coordinates, just as the paint tool does.

The other use case for using the time is the airbrush. I looked at it time ago and looked again due this thread, first idea was checking the remaining of airbrush timer, but there seems to be none (yet?). It is required as airbrush stamps every X time, but if you move faster, the effect of time is ignored, getting stronger stampings than what really should happen.

So no, there is no current use of velocity, but just cos it is not implemented, and thus nobody thinks about possible uses. Sounds a bit recursive. ;]

Ok - there is a velocity setting on the animated brushes, so we broke the recursion...we just need a volunteer to factor out the ink tool use of it, and implement a velocity calibration curve for the strokes.
:-)

GSR