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
[Gimp-developer] Fwd: is watercolor (brush color blending mode)...
-- Forwarded message -- From: Theodore Imre [EMAIL PROTECTED] Date: Sun, Jul 27, 2008 at 9:56 PM Subject: Re: [Gimp-developer] is watercolor (brush color blending mode)... To: Øyvind Kolås [EMAIL PROTECTED] hi, as i am reading this, im getting more and more interested in the way gimp works and handles virtual and hd memory usage. I do not think that gimp should emulate real materials, and i do not consider a brush color blending dynamics - a watercolor emulation. As i read,gegl makes it possible to implement some very powerful features that are likely to make gimp grow a lot. I always thought that applications that have that blending brush dynamics dont actually store variables in each pixel on the screen (like paint quantity and thickness)- like painter or artrage. 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? 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. As beautiful as it is,the user doesnt have as much control over the color as in the simpler way-just color blending as in sai or especially 4thpaint- in 4thpaint the way it works visually seems simple- but there its variables,set differently on different bruses make it the ultimate blending tool- its so easy and enjoyable to get the right colors. Brushes with these dynamics are very powerful. 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) Souichi thank you for considering continuing your work on such an application, i really do hope you port/develop it to linux,because it is very much likely it will fulfill the big gap.If you do,i would love to try it,use it,tell everybody about it. It might take you a day or two to implement in gogh or mtpaint,but for thats because you have the power to do it,while most people like me,who just need it,its impossible.Mtpaint does not support layers,alpha channel or an eraser tool,would be cool if gogh had that feature.. 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 . 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.. On Sun, Jul 27, 2008 at 8:38 PM, Øyvind Kolås [EMAIL PROTECTED] wrote: 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
Re: [Gimp-developer] Fwd: is watercolor (brush color blending mode)...
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 ___ 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
