branches/koffice/1.6/koffice/krita/plugins/filters

[Cyrille Berger]

> > 1) filter who works only on one pixels (invert, convolution, wave...)
>
> I'd more say
> 1a) filters that only use a limited amount of pixels around a changed area.
> They use the same pixels as source and destination (invert, convolution).
> 1b) filters that only change a limited amount of pixels around a changed
> area, but want to use other pixels as a source (wave).
convolution behave as wave, I think we should find a solution where the whole 
paintdevice is given to the filter, even if the work of the filter is limited 
to a QRect.

> (...)
>
> 4) Filters that cannot be implemented as an adjustment layer due to the
> random nature of the filter. Filters that use random generators are prone
> to this (surprisingly, the effect is tolerable with Noise and Random Pick).
> Raindrops isn't only way too slow, it also adds rain _randomly_ on the
> image (or dab you changed).
well at least for somerandom it's still possible to have a deterministic 
randomness wether it depends of X,Y or not.

> 5) Gimp filters that might be any of the above, but that we can't know
> because the code is too optimized to be clear if it can be put in a
> specific category of the above list (oilpaint).


> > My opinion is that all three should be available with the adjustement
> > layer, eventually with a warning of slowliness for type 3.
>
> Currently, we only support 1a, with an added exception that the 'limited
> amount' equals exactly '1'. We definitely should also support the complete
> of 1a, and 1b. Actually, we'd be able to support most of already 1b if the
> filters didn't assume src == dst (and copy src to dst first in the other
> case).
>
> > Most of type 1 are allready available. Once CoW tiles are available, all
> > of them would be possible.
>
> Most likely, yes. But still I'd rather not clone an entire layer, even if
> it's only CoW, if the filter only needs to invert a single pixel of it, and
> we know beforehand that it'll only need this one pixel. Similar examples
> are obvious.

That's an other question, do we still need to have src and dst seperated ? The 
more I think of adjustement layer, the more I think the answer is yes, CoW 
tiles isn't enought. And we need to fix everywhere code wich assumes src == 
dst like convolution.

> > For type 2, there is two possibilities:
> > - we consider that the statistics aren't much changed by each strokes,
> > and we only recompute them occasionally
>
> Possible, so you mean that you actually only redraw the adjustment layer
> after the stroke ended? This can reasonably work with Autocontrast, I
> guess.
>
> > - or, this can work at least for fast color transfert and for
> > brightness/contrast, somehow we give the area to apply to the filter, and
> > he removes the old statistics (rereading the image) and add the new one,
> > and can process on the new pixels for a small computational cost, it
> > works best, but I don't know if it will covers all case of type 2
>
> Brightness/Contrast is a filter of type 1a, subtype: only needs a single
> pixel.
Sorry I meant autocontrast ;) And I had rather see only one type of 
implementation, I don't see the need to solve twice this issue. And actually 
I think solution 2 is the best.

>
> (...)
>
> Anyway, bottomline of how I see it, in 2.0 we should be able to use 1a and
> 1b filters, some of 2 and 3, decided on a case-by-case review of how the
> filter performs. But remind that all of the cases need extra code.
if it was easy, it wouldn't be interresting ;)

-- 
--- Cyrille Berger ---