Summer of Code
mw_triad at users.sourceforge.net
Mon Mar 24 16:48:02 CET 2008
Boudewijn Rempt wrote:
> Well, painting with filters has been possible for ages. I haven't been able to
> run Photogenics for a long time (it used to work on Linux, but as a binary
> only package it broke ages ago).
> However, we do have an architectural issue here. Krita is designed like this:
> KisTool: determines the begin and the end point point of a line that will be
> KisPaintOp: brush engine: completely determines what actually happens between
> the begin and th end that KisTool told KisPaintOp to paint.
> The key here is "completely". It is impossible to constrain what KisPaintOp
> does. It needn't even use the composite op or opacity setting in the tool's
> option widget.
Maybe this is being over-engineered. I guess what I would like to see
is, we have KisTool (KisStrokeTool?) that determines the stroke, the
stamp/tip/whatever (KisPaintTool?) that takes the stroke (preferably in
real time, of course!) and decides what pixels actually get "paint"
along the stroke, and then the Op (KisPaintEngine? KisPaintOp?) that
decides what to do based on that set of pixels. Some types of "paint"
would expand the mask from the s/t/w to simulate "bleeding", "wetness", etc.
The point: for filters (and "digital paint"), you use the mask exactly
as you get it from the s/t/w. If you want/need bleeding when painting
with a filter, use a filter layer and paint on the mask (but now you can
use ink, watercolors, etc, on the mask...). Painting with a filter would
be quite different from painting the mask of a filter layer, because
overlapping strokes apply the filter multiple times (even overlapping
segments of a single stroke might do this), and of course you are
directly manipulating a layer...
Save soybeans! Avoid TOFU! (http://en.wikipedia.org/wiki/Posting_style)
More information about the kimageshop