Paint core beyond 2.6
This discussion is connected to the gimp-developer-list.gnome.org mailing list which is provided by the GIMP developers and not related to gimpusers.com.
This is a read-only list on gimpusers.com so this discussion thread is read-only, too.
Paint core beyond 2.6 | Alexia Death | 07 Jun 22:22 |
Paint core beyond 2.6 | David Gowers | 08 Jun 02:07 |
Paint core beyond 2.6 | Alexia Death | 08 Jun 10:48 |
Paint core beyond 2.6 | David Gowers | 08 Jun 15:32 |
Paint core beyond 2.6
This is a planning idea for new PaintCore for GIMP 2.8 or beyond.
1: The "Why?".
Current paint core is just not flexible enough and migration to GEGL based paint core is planned anyway. So why not do the best possible paint core since we are redoing it anyway?
2: What is the goal?
In general: Best possible digital "painting" tools. That should NOT include any natural painting things like watercolor emulation or alike but full featured tool for use on digital medium for image processing, touch-up etc.
What does the above mean?
* Easily extensible framework for creation of painting tools
* Fully dynamic painting, meaning that every adjustable aspect is user input
controllable
* Easily distributable paint tool presets that allow a the complete tool
context to be saved and loaded either on same or different machine
How I see that happening?
Step one:
Event handler for paint tools.
This is a very important bit for fully featured tools. All devices have
some dynamic properties that are useful in painting on the digital canvas.
* Mice have velocity(and acceleration), cheap tablets add pressure, more
expensive ones may add even more axis.
* All movement has direction
* Purely calculated axis like random can be extremely useful.
* Paint tools want events at a constant distance or at a constant
distance AND rate.
Devices will never provide exactly what is needed so adjustment is
required. The extra events need to be discarded and events that are missing
interpolated. The method of interpolation depends on the axis in question.
So event handler should:
* be able to handle a number of device axis and apply per device curves
* support calculated axis based on what device provides and also support
applying device curves
* support a dynamic selection of arbitrary purely calculated axis
(random, iterator, sin, cos, sawtooth, box);
* be able to deliver constant distance and constant rate events
Step two:
Paint Core
Paint core should provide framework for interacting with the canvas,
controlling the event handler and the saving and loading of paint tool
contexts as Paintbrushes, Erasers, Sponges etc with previews. Paint core
should also facilitate curves based mapping of event handler axis to tool
parameters. All paint tools expose parameters that may be mapped to any axis
event handler can provide.
Step X:
Paint tools:
Brush tool: Simple painting tool, support for all current brush formats
is a must. Must support at least scaling and rotation of brushes.
Airbrush tool: Almost the same as brush tool but orders constant rate of
events from event handler.
etc tools: Use paint tool framework, only the paint action itself
differs.
That's just my Idea for the step two of my last piece from a while ago on brushes in GIMP.
Sven, Pippin, Peter, everybody - comments?
Paint core beyond 2.6
Hi Alexia,
On Sun, Jun 8, 2008 at 5:52 AM, Alexia Death wrote:
This is a planning idea for new PaintCore for GIMP 2.8 or beyond.
[...]
* support a dynamic selection of arbitrary purely calculated axis (random, iterator, sin, cos, sawtooth, box);
A 'Dynamic selection'? what does this mean? Just that you are free to choose one of these?
* If you treat random, etc as axis, you need to provide a method of scaling them, or can you guarantee that they all range 0 .. 1.0 ?
I think sin and cos could be implemented as a subcase of 'custom': a custom curve input.
* be able to deliver constant distance and constant rate events
You mean events at a constant distance spacing or a constant time spacing? According to what you wrote above, a 'distance' axis might be good. Is there any other way that the 'Use color from gradient' or 'Fade' options could be replicated?
Paint core beyond 2.6
On Sunday 08 June 2008 03:07:15 David Gowers wrote:
* support a dynamic selection of arbitrary purely calculated axis (random, iterator, sin, cos, sawtooth, box);
A 'Dynamic selection'? what does this mean? Just that you are free to choose one of these?
In my vision you could choose arbitrary number of these including the same item twice and then apply different curves to both instances. I'm not 100% how that can be implemented tho.
* If you treat random, etc as axis, you need to provide a method of scaling them, or can you guarantee that they all range 0 .. 1.0 ?
They would all have range of 0.0...1.0 just like random, velocity etc now in SVN.
I think sin and cos could be implemented as a subcase of 'custom': a custom curve input.
All these calculated axis would be a sort of custom. Allowing a free formula type is an option as well but It may be harder to implement.
* be able to deliver constant distance and constant rate events
You mean events at a constant distance spacing or a constant time spacing?
I mean both. The dream is that paincore would only need to worry about painting a stamp at a given event, the "where?" part is all handled by paint core. The distance in this case is the stamp spacing.
Is there any other way that the 'Use color from gradient' or 'Fade' options could be replicated?
Replicated? It's paint cores job to provide these two features and any other numerically controlled options and possibly expose their control values for event mixed influence.
Theres a check grid now in SVN. In my vision in tool pane each option that supports it has a checkbox to turn dynamics on and off and a button to curves about that specific parameter. Additionally there are sliders for scaling the dynamics as a whole for quick adjustment. If you load a tool the changes made are forgotten. They are just adjustments to the current ie paintbrush, where as changes in curves create and "unsaved" tool that can be marked that way so the user knows that they need to save it either as a new tool or overwriting the parent.
-- Alexia
P.S redirecting back to list,
Paint core beyond 2.6
Hi Alexia,
On Sun, Jun 8, 2008 at 6:18 PM, Alexia Death wrote:
* be able to deliver constant distance and constant rate events
You mean events at a constant distance spacing or a constant time spacing?
I mean both. The dream is that paincore would only need to worry about
Yes, that's what I meant, sorry.
painting a stamp at a given event, the "where?" part is all handled by paint core. The distance in this case is the stamp spacing.
Is there any other way that the 'Use color from gradient' or 'Fade' options could be replicated?
Replicated? It's paint cores job to provide these two features and any other numerically controlled options and possibly expose their control values for
What you describe is redundant if you expose those separately... since they currently effect either color or opacity according to distance from start of stroke. That's why I said replicate.
I think you could improve this idea a lot by making some mockups, where you can easily spot and eliminate unnecessary redundancies. (I'm certain that there are quite a few neither of us has noticed.)
Theres a check grid now in SVN. In my vision in tool pane each option that supports it has a checkbox to turn dynamics on and off and a button to curves about that specific parameter. Additionally there are sliders for scaling the dynamics as a whole for quick adjustment. If you load a tool the changes made
This sounds pretty good! I'd like to suggest the use of bottom-scaling
as well as top-scaling here:
that is, allow the quick adjustment to either scale down like 0..1
becomes 0..0.5 (scale == 0.5) or scale down like 0..1 becomes 0.5..1.0
(scale - 0.5). I can certainly vouch that I've wanted this a lot of
times for Size -- the minimum size ends up far too small sometimes.
are forgotten. They are just adjustments to the current ie paintbrush, where as changes in curves create and "unsaved" tool that can be marked that way so the user knows that they need to save it either as a new tool or overwriting the parent.
Yes, mockup sounds like it would help. I think what you describe above
doesn't yet warrant the description of creating new user-tools. Mainly
because it does not support some things that are important at a
tool-level: Hard Edge, Clone-like behaviour.
Consider talking to peter specifically about this -- he has the 'Dabs
of paint' idea, which IMO is more correct than associating settings
with either a brush or a tool; In the same way that acrylic paint on a
brush has quite different physics than watercolor paint on the same
brush. What you are talking about might be called something more like
a tool-tip (yes, unfortunate but accurate; how about pen-tip?
paint-tip?)
IMO a good distinction is like:
* tool : what you are doing and how you are doing it
* tip : the precise effect that occurs when painting
* brush: the area and amount in which it is applied.
* paint : all of the actual pixels that end up being applied.
HTH, David