---------- 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 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 mailing list