On Sat, Jul 26, 2008 at 3:28 PM, Theodore Imre wrote:

...

It's unpleasant when people take this sort of angry and demanding tone for free software that they haven't contributed to. It's hard to give a calm response without feeling like a wimp.

-- Bill

Hi Theodore,
On Sun, Jul 27, 2008 at 7:58 AM, Theodore Imre wrote:

...
is watercolor (brush color blending mode) going to be avaiable in gimp's development version? I dont see why its not there,while it has already been implemented back in 2.4 (Sakaguchi's work)

Sakaguchi? Souichi Takashige is the guy AFAIK.

http://www.youtube.com/watch?v=SIg8Omew9Ps http://www.mail-archive.com/gimp-developer@lists.xcf.berkeley.edu/msg15250.html

Do you have any idea how badly a graphic artist wants this to be avaiable on linux? Havent you heard of applications such as sai paint tool,nekopaint, or 4thpaint (all not working correctly in wine) ?

Rhetoric is counterproductive to getting anything implemented, as Bill says. Work is relevant. Your work. If you want it, take responsibility for making it happen.

I would like to ask only two things: 1.is this going to be avaiable in some of the 2.5 releases, because if it is,i'm gonna bug tests it

No, it is not going to be available in 2.5, unless you fix the patch or persuade Souichi Takashige to do so. The patch required a lot of tweaking to apply successfully, and must now account for Alexia Death's new brush dynamics system. Nobody ever updated it, probably because it was so hard to patch initially that virtually no-one actually got to try it out.

2.If not, is it possible for a patch (for gimp 2.5.x) to come out,or some way to incorporate it into my gimp,because i want it very badly from ages..maybe at gimp-files.org ??

As above, yes if you or Souichi Takashige do it, otherwise no.

I've been search for a way to get to this brush feature with pressure sensitivity on linux for ages,i know lots of other people who do too..this is as important as anything else i love gimp for

Importance is a personal thing and GIMP is short on developers, so, getting any given feature implemented depends mainly on a person considering it important enough to do the work necessary to implement it properly.

HTH,
David

On Sun, 2008-07-27 at 00:28 +0200, Theodore Imre wrote:

...
is watercolor (brush color blending mode) going to be avaiable in gimp's development version?

In the short term, the "Krita" program (part of KDE) does have some colour mixing.

Do you have any idea how badly a graphic artist wants this to be avaiable on linux?

Different user communities want lots of different things, often very badly. Pretty much all of them want more bits per pixel, and if you did start working with colour mixing you would too, I expect :-) so that work has to be finished first. This was also said in the mail thread.

It's generally better to assume that the developers have at least a little imagination and knowledge of their area, rather than suggesting they might not have heard of colour mixing :-) There are only a few people doing active GIMP programming right now, though. Perhaps you could help out?

Liam

Hi,

1.is this going to be avaiable in some of the 2.5 releases, because if it is,i'm gonna bug tests it

No, it is not going to be available in 2.5, unless you fix the patch or persuade Souichi Takashige to do so.

Sorry, I'm currently working on another program, so I have not maintained the patch any longer.

GIMP will be fully non-destructive editor in the future, but I think that is not a good news for users who use GIMP as a painting tool. Non-destructive editing is convenient in some situations, but a lot of brush painting processes don't need to be non-destructive, and making all of them non-destructive is a waste of time and resources.

GEGL and GIMP are great work of cource, it is very powerful photo retouching tool. But it's not good for painting images from scratch since it lacks a lot of features specialized for painters (like view rotation and flipping.)

I think being general purpose program is a waste of time: code size will grow constantly and the architecture will be more and more complex. No one can maintain it. So GIMP should focus on the photo retouching, and other programs like Artweaver, Gogh, and MyPaint should focus on painting features.

-- Souichi TAKASHIGE

On Sun, Jul 27, 2008 at 4:46 AM, Souichi TAKASHIGE wrote:

Sorry, I'm currently working on another program, so I have not maintained the patch any longer.

GIMP will be fully non-destructive editor in the future, but I think that is not a good news for users who use GIMP as a painting tool. Non-destructive editing is convenient in some situations, but a lot of brush painting processes don't need to be non-destructive, and making all of them non-destructive is a waste of time and resources.

They do not need to be made fully non-destructive, for the paint core I have been experimenting with on top of GEGL[1] I have both a destructive and a non destructive version. The difference between them being that the destructive one continuously replaces the contents of a GeglBuffer instead of building a graph. Making things non-destructive doesn't necessarily imply additional work when creating brush painting processes if the infrastructure to do so exists. (I've mainly experimented with the destructive version thus far when I've had time since it is significantly faster than the non-destructive one which depends on better automatic cache purging to be more efficient.

1: http://pippin.gimp.org/tmp/soft-strokes.png

GEGL and GIMP are great work of cource, it is very powerful photo retouching tool. But it's not good for painting images from scratch since it lacks a lot of features specialized for painters (like view rotation and flipping.)

These are features that might easily be added on top of a GEGL based, both destructive and non-destructive paint core. At least if using hardware acceleration like the ClutterGegl view widget to display the final composite. At GUADEC this year I showed a mini painting app embedded in a presentation tool where I could freely rotate the GEGL paint demo and paint at it at any angle.

I think being general purpose program is a waste of time: code size will grow constantly and the architecture will be more and more complex. No one can maintain it. So GIMP should focus on the photo retouching, and other programs like Artweaver, Gogh, and MyPaint should focus on painting features.

For some things, like natural media simulation using cellular automata like approaches I tend to agree, this is also one of the few types of simulations that I think would be difficult to make work in a non-desctructive fashion. For other types of user empowering painting features I do think they can belong in GIMP as well, or perhaps in other applications built on top of GEGL.

/Øyvind K.

Hi,

They do not need to be made fully non-destructive, for the paint core I have been experimenting with on top of GEGL[1] I have both a destructive and a non destructive version. The difference between them being that the destructive one continuously replaces the contents of a GeglBuffer instead of building a graph. Making things non-destructive doesn't necessarily imply additional work when creating brush painting processes if the infrastructure to do so exists.

I'm very glad to hear that. I think keeping destructive brush tool is essential for painting tool. I will try to find the way to add features such as color blending when that code is merged into the svn tree.

But then, I have another question about destructive brush tool. How does the GEGL manage the non-destructive and destructive operations together? In my understanding, if we modify GeglBuffer directly with destructive operations, contents of the GeglBuffer can't be purged because we can't reproduce the brush strokes. That means all of the non-destructive operations prior to the last destructive operations can't be non-destructive any more. One solution is to have one GeglBuffer for each stroke, and combine them when update the display. But it costs too much memory when we make a lot of strokes -- and we *DO* make thousand of strokes when we draw an image -- compared to the current implementation which has a buffer per each layers.
Another idea is to separate destructive layers from non-destructive layers. The destructive layer can have only destructive operations, and GeglBuffer of this layer can be replaced repeatedly with no matter. I think this idea make sense.

If this question does not related to GIMP at all, I will post a new question to the GEGL ML. If the GIMP has to solve the problem, please tell me your idea to mix the destructive and non-destructive operations.

These are features that might easily be added on top of a GEGL based, both destructive and non-destructive paint core. At least if using hardware acceleration like the ClutterGegl view widget to display the final composite. At GUADEC this year I showed a mini painting app embedded in a presentation tool where I could freely rotate the GEGL paint demo and paint at it at any angle.

Great! I'm looking forward to see these nice features on the GIMP. --
Souichi TAKASHIGE

On Mon, 2008-07-28 at 01:19 +0900, Souichi TAKASHIGE wrote:

[...]

But it costs too much memory when we make a lot of strokes -- and we *DO* make thousand of strokes when we draw an image -- compared to the current implementation which has a buffer per each layers.

That's something that needs to be measured.

Don't forget that right now, the strokes are stored individually in the undo history anyway.

Liam

2008/7/28 Liam R E Quin :

On Mon, 2008-07-28 at 01:19 +0900, Souichi TAKASHIGE wrote:

[...]

But it costs too much memory when we make a lot of strokes -- and we *DO* make thousand of strokes when we draw an image -- compared to the current implementation which has a buffer per each layers.

That's something that needs to be measured.

I see.
It takes much memory when we draw brushmarks many times on the same area, I think that is very usual situation. Perhaps we should study the memory usage for this situation.

Don't forget that right now, the strokes are stored individually in the undo history anyway.

Yes and no. GIMP copies previous tiles prior to its modification, but that is part of previous layer image, not a stroke itself. GIMP can forget the undo cache, and do forget the undo cache (on program termination for example.)
On the other hand, GeglBuffers for each strokes should be kept persistently. That is a big difference between undo cache and contents of GeglBuffer.
But we can estimate the rough memory usage for the situation above from the memory usage of the undo cache. --
Souichi TAKASHIGE

On Sun, Jul 27, 2008 at 7:34 PM, Souichi TAKASHIGE wrote:

2008/7/28 Liam R E Quin :

On Mon, 2008-07-28 at 01:19 +0900, Souichi TAKASHIGE wrote:

[...]

But it costs too much memory when we make a lot of strokes -- and we *DO* make thousand of strokes when we draw an image -- compared to the current implementation which has a buffer per each layers.

That's something that needs to be measured.

I see.
It takes much memory when we draw brushmarks many times on the same area, I think that is very usual situation. Perhaps we should study the memory usage for this situation.

Don't forget that right now, the strokes are stored individually in the undo history anyway.

Yes and no. GIMP copies previous tiles prior to its modification, but that is part of previous layer image, not a stroke itself. GIMP can forget the undo cache, and do forget the undo cache (on program termination for example.)
On the other hand, GeglBuffers for each strokes should be kept persistently. That is a big difference between undo cache and contents of GeglBuffer.
But we can estimate the rough memory usage for the situation above from the memory usage of the undo cache.

The situation would be the same for GEGL once the bug in http://bugzilla.gnome.org/show_bug.cgi?id=502465 gets resolved. Since the part of the processing graph underneath the top most added stroke doesn't change, and it can be recomputed from the parameters of the nodes in the graph there is no need to always persist the actual pixels. This is a general optimization that also will help other parts of GEGL. Experimenting with the gegl-paint example in the GEGL sources will be a natural thing to do when fixing this bug. (The code in there should be easily modifiable to become full non-destructive again).

/Øyvind K.

On Sunday 27 July 2008 22:57:38 Theodore Imre wrote:

All such applications that i tried (sai,nekopaint,4thpaint) used a relatively low amount of virtual memory/cache space. So from what i read now, gimp cannot handle such a brush dynamics,because it is going to likely consume a lot of memory.How do these other applications manage to do it so lightly without much memory?

In my experience such applications offer little or no undo and as rule no layers. Either way its always a trade off. Shi, for example offers a rather limited sized canvas IIRC. And most of these trades an application meant for photo editing can not do.

Rotating the canvas is also a very usefull feature that is valuable when you draw with a tablet (you cannot rotate your tablet because hand-eye coordination is ruined,but rotating it on the screen makes it easier for one to get the right angles of lineart)

This I agree to. Sadly, since tablets cost A LOT of money there aren't many people even among developers who would be willing to spend time on features that are there for just tablet users. Theres so much more to work on and not enough people actually offering code. Ill just do what I can to make the paint tools as powerful as I can. And having had a look at the code in question... It will be a while before a gegl based paint core has any chances of replacing the current one. Theres too many features that would be lost with a replacement. A slow transformation perhaps, but all out replacement... I don't see that happening somehow.

But i really hope that Gimp doesnt just take design ideas from only photoshop and its tools and does not stick to photo manipulation only,while its foundations make it possible to grow in the right directions that make an artist use graphic software.

Like it or not GIMP is an Image Manipulation program. It can not and will not be a painting application. You may look at Krita and its developers to fill that need.

A brush color
blending mode would really make a big change and will make it a lot more enjoyable to use for drawing with a tablet.Gimp shouldnt really emulate real materials if it has that feature..

Blending mode? As in mixing colors on canvas? Please explain how this should work in your mind? It might not be very complicated to make a tool like that. Since I haven't taken a closer look at paint tools work at that level, so I probably could use the exercise. Trouble is, any extra tools will most likely shunned by core developers and adding it as an option for a paintbrush is not IMHO a clean solution.

-- Alexia

Hi,

2008/7/28 Øyvind Kolås :

The situation would be the same for GEGL once the bug in http://bugzilla.gnome.org/show_bug.cgi?id=502465 gets resolved. Since the part of the processing graph underneath the top most added stroke doesn't change, and it can be recomputed from the parameters of the nodes in the graph there is no need to always persist the actual pixels. This is a general optimization that also will help other parts of GEGL. Experimenting with the gegl-paint example in the GEGL sources will be a natural thing to do when fixing this bug. (The code in there should be easily modifiable to become full non-destructive again).

Thank you for your comment.
I don't how to recompute the destructive brush stroke yet. Or I might misunderstanding the meaning of "destructive." I thought destructive means "destroy image itself and cannot undo it nor redo it" unless we manage the undo cache. So it can't be non-destructive unless we save that cache forever.
But maybe it's better to check the source code of gegl-paint first. --
Souichi TAKASHIGE

Hi,

On Mon, Jul 28, 2008 at 9:39 AM, Souichi TAKASHIGE wrote:

Hi,

2008/7/28 Øyvind Kolås :

The situation would be the same for GEGL once the bug in http://bugzilla.gnome.org/show_bug.cgi?id=502465 gets resolved. Since the part of the processing graph underneath the top most added stroke doesn't change, and it can be recomputed from the parameters of the nodes in the graph there is no need to always persist the actual pixels. This is a general optimization that also will help other parts of GEGL. Experimenting with the gegl-paint example in the GEGL sources will be a natural thing to do when fixing this bug. (The code in there should be easily modifiable to become full non-destructive again).

Thank you for your comment.
I don't how to recompute the destructive brush stroke yet. Or I might misunderstanding the meaning of "destructive." I thought destructive means "destroy image itself and cannot undo it nor redo it" unless we manage the undo cache. So it can't be non-destructive unless we save that cache forever.

No, it's only destructive if we have no way of regenerating the cache as needed. With GEGL, we can cache just at the newest node in the graph. Stroke information can be fully stored in the node. Ah! I think I might see what you mean! If a stroke is made, then you modify the brush used when drawing it, the stroke may then look different.
This is a difficult problem really -- As I see it, we need to be able to keep brush data in the graph (or as an auxilary data managed by GEGL+GIMP), or maintain a history of each brush, for an indefinite length of time. The same would need to apply to palettes, gradients, patterns etc.

HOWEVER.. If, once a resource was used in the graph, it was marked unchangeable, that could give a simple solution: then you just duplicate when you need to change it. Patterns would require a proper duplicate command, with this (they don't have one currently); otherwise it seems pretty easy to implement. (it would also require better memory/resource loading management, in consideration of large/animated brushes)

But maybe it's better to check the source code of gegl-paint first. --
Souichi TAKASHIGE

Krita's color blending is not really what Souichi had started with his patch. From my observation that tool is trying to emulate real paints,and when one dips the brush over the colored parts of the canvas,it absorbs part of the color, altering the color inside the brush, and after you draw on a clean part, your color had changed.

Actually, although Krita seeks to emulate natural media, it doesn't mean that it has to be a natural-media only program.

The nice thing about Krita is that it is very modular, so essentially any tool can be written as a plugin instead of tampering with the core.

Also, the Krita developers are pretty friendly and open- minded in my experience. Basically, they may not have the time or interest to implement what you want themselves, but if you can ask someone to port Souichi's patch as a new tool for Krita, they'll probably accept.

Right now they've gotten into feature-freeze because of the future KOffice 2.0 release, but then again, Gimp is also in a particular situation right now because it's finally being ported to GEGL after several years, so it will likely be enhancing its image manipulation functions first.

Also, KOffice 2.0 will have Windows and Mac ports, though I hear they aren't very efficient ones yet. If you discuss with the Krita community, you may have a better shot at implementing the blending brush eventually than with Gimp.

photoshop is also a image manipulating application,but its brushes
have some color dynamics and its developers are working on making it a painting application,as much as photo manipulator.In fact they are trying to turn it into an universal tool- latest photoshop even supports 3d layers.I doubt gimp will ever do that if all of its developers are keeping it in the photo manipulation area.That would also keep it less feature rich

Oh no. 3d layers are HORRIBLE. Its very, very slow and its far easier to do that on a 3d package. I really don't expect that from GIMP.

But I do expect some more brush dynamics (like rotation of the brush as you move it).

Hi,

No, it's only destructive if we have no way of regenerating the cache as needed. With GEGL, we can cache just at the newest node in the graph. Stroke information can be fully stored in the node.

I'm confused.

From my understanding, if stroke information is stored in the node,

then the stroke can be regenerated, and that operation will be non-destructive since the cache can be regenerated. I think David says about "non-destructive" brush operation. I saw source code of gegl-paint. It seems that gegl_vector stores the information of the path, so I think it is also about non-destructive brush tool.

On the other hand, Øyvind says that we can implement "destructive" brush. I think being "destructive" implies that there's no way to regenerate the stroke since being able to regenerate the stroke means that the cache is regeneratable, so the operation must not have any path information.
My concern is about this case.

Let's say, If the following operation sequences are executed, how can we undo and redo the brush operation (C) and (D)? And what will happen if we change the prarameter of the operation (B)? (A) load an image from external resource. (B) do filter operation, "non-destructive." (C) do brush operation, "destructive." (D) do another brush operation, "destructive." (E) do filter operation, "non-destructive."

If my assumption is wrong, please let me know. --
Souichi TAKASHIGE

Hi,
On Tue, Jul 29, 2008 at 12:17 AM, Souichi TAKASHIGE wrote:

Hi,

No, it's only destructive if we have no way of regenerating the cache as needed. With GEGL, we can cache just at the newest node in the graph. Stroke information can be fully stored in the node.

I'm confused.
From my understanding, if stroke information is stored in the node, then the stroke can be regenerated, and that operation will be non-destructive since the cache can be regenerated. I think David says about "non-destructive" brush operation.

I was only addressing what you said "So it can't be non-destructive unless we save
that cache forever.", by indicating why little caching is needed for the non-destructive case -- the actual parameters of the operation are kept.

I saw source code of gegl-paint. It seems that gegl_vector stores the information of the path, so I think it is also about non-destructive brush tool.

On the other hand, Øyvind says that we can implement "destructive" brush. I think being "destructive" implies that there's no way to regenerate the stroke since being able to regenerate the stroke means that the cache is regeneratable, so the operation must not have any path information.
My concern is about this case.

Let's say, If the following operation sequences are executed, how can we undo and redo the brush operation (C) and (D)? And what will happen if we change the prarameter of the operation (B)?

After a destructive operation, you cannot change parameters of earlier steps -- the information necessary to do so no longer exists. Therefore, after C happens, changing B is meaningless -- B no longer exists in any sensible way.

I think this is a subject where it is very easy to find yourself confused. (I certainly am confused!)

I personally believe that destructive editing doesn't have merit by itself, it doesn't save time or improve the responsiveness of a program.
Rather, it is worth using as a tool similar to 'clear undo history' -- in GEGL, it is like collapsing a branch of the graph into a single leaf.

I also think it's important to keep in mind, when working fully with GEGL, undo and redo would be implemented by modification of the GEGL graph. I admit I do not understand how there can really be any destructive operation, in that framework; unless you allow old graph modifications to expire (and turn that branch into a GeglBuffer)

(A) load an image from external resource. (B) do filter operation, "non-destructive." (C) do brush operation, "destructive." (D) do another brush operation, "destructive." (E) do filter operation, "non-destructive."

If my assumption is wrong, please let me know. --
Souichi TAKASHIGE

Hi,

2008/7/29 David Gowers : [...]

I was only addressing what you said "So it can't be non-destructive unless we save
that cache forever.", by indicating why little caching is needed for the non-destructive case -- the actual parameters of the operation are kept.

I see. Thank you for your explanation.

Let's say, If the following operation sequences are executed, how can we undo and redo the brush operation (C) and (D)? And what will happen if we change the prarameter of the operation (B)?

After a destructive operation, you cannot change parameters of earlier steps -- the information necessary to do so no longer exists. Therefore, after C happens, changing B is meaningless -- B no longer exists in any sensible way.

[...snip...]

I also think it's important to keep in mind, when working fully with GEGL, undo and redo would be implemented by modification of the GEGL graph. I admit I do not understand how there can really be any destructive operation, in that framework; unless you allow old graph modifications to expire (and turn that branch into a GeglBuffer)

I think so too. So I wonder how can I manage non-destructive and destructive operations together without corrupting its non-destructive semantics.

I personally believe that destructive editing doesn't have merit by itself, it doesn't save time or improve the responsiveness of a program.
Rather, it is worth using as a tool similar to 'clear undo history' -- in GEGL, it is like collapsing a branch of the graph into a single leaf.

I have no idea when to use non-destructive feature as for painting work with a brush tool. It's more natural and more intuitive to make new strokes on top of existing one to modify the part of the existing strokes rather than to modify the parameters of existing path. So current implementation is enough.
Replacing brush tools with a non-destructive one has little merit, and it has a risk to be slower and more memory consuming in certain situations for painting artists.

Making a brush tool non-destructive itself is a great work, so I think it's better to separate destructive layers from other non-destructive operations. Painters may use destructive layer to avoid the risk to be slow, and others may use non-destructive one.

I think it is a GIMP's design matter rather than the implementation problem of the GEGL.
--
Souichi TAKASHIGE

On 7/28/08, Souichi TAKASHIGE wrote:

Hi,

No, it's only destructive if we have no way of regenerating the cache as needed.
With GEGL, we can cache just at the newest node in the graph. Stroke information can be fully stored in the node.

From my understanding, if stroke information is stored in the node, then the stroke can be regenerated, and that operation will be non-destructive since the cache can be regenerated. I think David says about "non-destructive" brush operation. I saw source code of gegl-paint. It seems that gegl_vector stores the information of the path, so I think it is also about non-destructive brush tool.

It is, right now that test program is destructive in that it forces a save/merge-down of the stroke as a temporary workaround until cache management in GEGL becomes better.

On the other hand, Øyvind says that we can implement "destructive" brush. I think being "destructive" implies that there's no way to regenerate the stroke since being able to regenerate the stroke means that the cache is regeneratable, so the operation must not have any path information.

The task of the painting operation is to provide the rendered result for a series of input events/coordinates, as well as a configuration for how it should be rendered. The code is written in a manner that makes it possible to append to the path and recompute a minimal region (semi working, but has some visual artifacts). All the things GIMP currently do can be expressed using this. It can also be easily extended to store line width and opacity varying along the stroke.

When it comes to implementing more destructive like buffer access for performance reasons one could implement an operation that operates on a GeglBuffer in-place. It would still be possible to replay it from history, but there wouldn't be valid caches for each operation, and the replay would be much more expensive. We could add a smaller undo stack for the buffer though adding support for undo tiles for GeglBuffers has existed in the past and could be resurrected. Such a smaller undo stack might be useful, but that is probably something to keep in mind later after purging of caches, and copy on write works better.

I am not actively pursuing experimenting with this at the moment, but there is enough proof of concept code that it should be possible to start porting the current GIMP tools to such an infrastructure. This would also be the moment that the GIMP tools gain higher bitdepth retouching capabilities, initially it would make sense to port it in such a manner that it works, but is perhaps slow. Then to optimize as needed. How it makes sense to store this in a graph in GIMP probably should wait until the projection of the layer stack in GIMP has been ported, then it would be possible to add the strokes as a layer group or similar.

/Øyvind K.

Hi,

2008/7/29 :

It is, right now that test program is destructive in that it forces a save/merge-down of the stroke as a temporary workaround until cache management in GEGL becomes better.

[...snip...]

The task of the painting operation is to provide the rendered result for a series of input events/coordinates, as well as a configuration for how it should be rendered. The code is written in a manner that makes it possible to append to the path and recompute a minimal region (semi working, but has some visual artifacts). All the things GIMP currently do can be expressed using this. It can also be easily extended to store line width and opacity varying along the stroke.

When it comes to implementing more destructive like buffer access for performance reasons one could implement an operation that operates on a GeglBuffer in-place. It would still be possible to replay it from history, but there wouldn't be valid caches for each operation, and the replay would be much more expensive. We could add a smaller undo stack for the buffer though adding support for undo tiles for GeglBuffers has existed in the past and could be resurrected. Such a smaller undo stack might be useful, but that is probably something to keep in mind later after purging of caches, and copy on write works better.

Thank you for your explanation.
Now I understand what you mean "destructive", and your idea of brush implementation. Basically brush operations are ready to be non-destructive in that it has a path information. And we can choose destructive operations instead of default cache updating algorithm for better performance as needed. I think implementing undo cache is a good idea.

My main concern is about the performance of the brush processing both for speed and memory usage.
I'm anxious about the performance a little yet, but I hope GEGL to have enough performance in the future. --
Souichi TAKASHIGE