Whither Krita?

[Moritz Moeller]

On 09/25/2009 07:00 AM, Sven Langkamp wrote:
> I think the "from scratch" was targeted at you reyes proposal.

REYES rendering can be used to render procedural brushes. This would be 
part of the brush engine. From scratch? Depends on you definition of 
that term.
There are 4 OSS REYES implementations I'm aware of. Lots of code to look 
at and steal from. Plus, since it is only 2D what one needs, lots of 
simplifications to the aforementioned code. :)

> It's always the question how much you want expose the node system to the
> user. Some users might be overwhelmed by it.

Totally. But you can easily have a Beginner Mode with a layer stack that 
works like Photoshop or the like. This is essentially just a single 
chain of nodes w/o branches.
If you allow layer groups, you get nesting. AfterEffects allows netsted 
compositions. You can even view them as a node graph (at least you 
could, in the past). But you can't edit them. Adobe had an internal 
version that allowed editing the node tree a few years back, essentially 
making AfterEffects a full-blown node-based editor.
However, product managament was too scared this would alienante the 
current user base and there were othe reasosn too, why it ultimately 
never shipped (performance certainly one of them, AfterEffects is dead 
slow compared to something like Nuke).

What I'm getting at is: in Beginner Mode you have a layer stack. At any 
time, you can view this as a node tree to better undertand how the wto 
relate to each other.
This node view is read only, in Beginner Mode.
In Normal Mode, the node tree becomes editable. Once edited, the edits, 
if they can't be reflected in the stack metaphor, require Normal Mode to 
be tweaked.
All parts of the node tree that were created in Beginner Mode and not 
affected by the edits are still shown in the Layer palette.
This is btw more or less straight from the white paper I wrote for 
Eclipse 4.0 (the image editing app, not the IDE), in 1998.

There are many ways to hide complexity from a user w/o sacrifcing power

> Editing draw strokes might be nice if you do it like MyPaint only for
> the last stroke. It gets more complicated to use if you want to modify
> single path points, just try to modify a calligraphy stroke in Karbon.

I'm not sure what complication you talk about? The brush editing I 
propose has got nothig to do with the lame (sorry) way Karbon or any 
other vector app I ver used (Corel, Illustrator, Inkscape) handle these 
strokes, after initial creation.

The Eclipse 4 whitepaper contained a wole bunch of ideas on editing 
natural media strokes that were far beyon point edting. In fact, while a 
needed feature, point edting is probably the one method artists using 
natural media would want to use least. And that is probably what you 
were getting at.

If you have stroke whose thickness you are happy with, you can redraw 
just a part of it. Drag-Select the part of the stroke you want to edit 
(along the length), put down your stylus, redraw.

There are bunch of options how this can be mapped back to the stroke.
One way would be to just connect the stroke drawn with the bits that 
weren't selected.
Another way is to have a guide marker run along the stroke at a constant 
pace and the user just provides feedback for the paramter they want to 
edit, on the tablet (e.g. position, pressure, angle, tilt, etc.)
Yet another way would be to map the length of the edited bit to the 
distance the stylus moved on the tablet by a factor. If the stylus is 
not at the same position at the end, the part of the original stroke 
that comes after just gets moved to fit.
Yet another way would be to just warp the stroke into the selected bit 
(the unselcted bits of the stroke stay absolutely put). This is 
admittedly hard to provide visual feedback for, while drawing.

There were 4 or 5 other methods. What they all had in common was that 
the artist used the stylus continuously to do the editing and by that I 
mean he did not use the stylus to select and move individual points of 
the spline definiting the pricinpal direction.

One thing to keep in mind is that positoon, width and angle are just the 
very basic parameters of a stroke.
But a procedural brush possibly has dozens of others.
Allowing these to be edited, in a natural way, using the stlyus 
continuiosuly, is a core interface metahphor a good procedural brush 
system has to employ, imho.

But this is talking about the UI already, I was, so far just talking 
about implementation. :)

> Saving the path would get a possible maintainance problem as future
> paintops have to work in the same way to keep the image looking the
> same. If you send someone a picture he needs all the paintops you used
> to create your image, so you would have to included the whole image as
> fallback.

That problem exists with text layers too. You need the fonts to render 
them correctly. That is why Text layers are saved as bitmaps too, in PSD 
files. And such dependencies and version mismatches for file format 
features are the reasons why a PSD file always contains a flattened 
image of the whole composition.
Essentially, anything that depends on a plug-in componnent which can not 
be assumed available on a system opening the image must be stored in a 
flattened way.
As with text, I'd actually store the outlines of the letters used, or 
even the whole font, if the font allowed embedding (this is alegal 
problem, not a technical one).
Similarly, for procedural brushes, one could store as much 
parametrically, as possible to re-create the brush at the intended 
rendering res for the image (say, 300ppi) if the paintop wasn't available.
And certainly, this should be an option, so one can save files of much 
smaller size if all dependecies can be assumed to be present, when 
opening the image again.

.mm