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

[Bart Coppens]

On Thursday 07 September 2006 09:50, Cyrille Berger wrote:
> 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).
> 2) filter who works only on one pixels but needs global statistics (color
> transfert)
Autocontrast as well.
> 3) filter who need all the image all the time (wavelet noise reduction)
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).
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.

> 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.

> As for type 3, we can use a timer before the last stroke and the update,
> or(and ?) have the filter be applied in background.
I don't think this will work from a user perspective. Most of these are pretty 
slow. And with pretty, I mean really slow ;) I guess some of them might be 
possibly not too slow, but a lot of them will be (think CImg, Raindrops if 
you'd put it in this category).

> Note: for random filters, I think the best solution for them is to use a
> seed base random generator, even if the end results is correct, painting
> get "annimated" with them
I don't think this will work for raindrops and others, due to the fact that 
most of these don't depend on (x,y) for their randomness afaik, but just use 
random().

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.

Bart