Re: [Gimp-developer] is watercolor (brush color blending mode)...
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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] is watercolor (brush color blending mode)...
Hi, On Tue, Jul 29, 2008 at 12:17 AM, Souichi TAKASHIGE [EMAIL PROTECTED] 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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] is watercolor (brush color blending mode)...
Hi, 2008/7/29 David Gowers [EMAIL PROTECTED]: [...] 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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] is watercolor (brush color blending mode)...
On 7/28/08, Souichi TAKASHIGE [EMAIL PROTECTED] 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. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/http://ffii.org/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] is watercolor (brush color blending mode)...
Hi, 2008/7/29 [EMAIL PROTECTED]: 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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] is watercolor (brush color blending mode)...
On Sun, Jul 27, 2008 at 4:46 AM, Souichi TAKASHIGE [EMAIL PROTECTED] 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. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ http://ffii.org/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] is watercolor (brush color blending mode)...
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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] is watercolor (brush color blending mode)...
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 -- Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/ Pictures from old books: http://fromoldbooks.org/ Ankh: irc.sorcery.net irc.gnome.org www.advogato.org ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] is watercolor (brush color blending mode)...
On Sun, Jul 27, 2008 at 7:34 PM, Souichi TAKASHIGE [EMAIL PROTECTED] wrote: 2008/7/28 Liam R E Quin [EMAIL PROTECTED]: 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. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ http://ffii.org/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] is watercolor (brush color blending mode)...
2008/7/28 Liam R E Quin [EMAIL PROTECTED]: 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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] is watercolor (brush color blending mode)...
Hi, 2008/7/28 Øyvind Kolås [EMAIL PROTECTED]: 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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] is watercolor (brush color blending mode)...
Hi, On Mon, Jul 28, 2008 at 9:39 AM, Souichi TAKASHIGE [EMAIL PROTECTED] wrote: Hi, 2008/7/28 Øyvind Kolås [EMAIL PROTECTED]: 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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] is watercolor (brush color blending mode)...
On Sat, Jul 26, 2008 at 3:28 PM, Theodore Imre [EMAIL PROTECTED] 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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] is watercolor (brush color blending mode)...
Hi Theodore, On Sun, Jul 27, 2008 at 7:58 AM, Theodore Imre [EMAIL PROTECTED] 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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] is watercolor (brush color blending mode)...
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 -- Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/ Pictures from old books: http://fromoldbooks.org/ Ankh: irc.sorcery.net irc.gnome.org www.advogato.org ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] is watercolor (brush color blending mode)...
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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
