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

[Cyrille Berger]

> > well at least for somerandom it's still possible to have a deterministic
> > randomness wether it depends of X,Y or not.
>
> Hmmmm? If it doesn't depend (explicitly or implicitly) on the coordinates,
> how will you make it deterministic?
>
> > 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.
>
> Well, as far as I remember, the idea has always been to force dst == src,
Not at all :) What would be the point of creating an API with a function that 
takes two parameters that need to be equal ? At the origin of time, when I 
first wrote KisFilter, it would take only one PaintDevice, then a little bit 
later I added the two parameters (I don't remember what use I had in mind at 
this time, filter tool, or allready the gallery) but in my mind it was clear 
that dst and src couldn't be assumed to be equal.

> but I can't remember the reasons for it. I'm sure there were good reasons,
> perhaps speed and/or complexity issues? With dst==src, you can use a rect
> iterator as a source, and a rect iterator as destination, whereas with
> src!=dst, you'll need 2 hline iterators and a while loop, which is just
> slightly more complex and probably slightly slower?
hum yes it would. hum, on the other hand when KisFilter was designed, rect 
iterators didn't exist... and with nextRow/nextCol, line iterators are closer 
to the speed of rect... rha... pfff :(

> Just guessing, though. 
> But yeah, with adjustment layers, dst!=src makes sense.
as for the filter paintop, even if I have no idea of how it works nowdays.

> > 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.
>
> It is, but I'm not sure how feasible it is.
well, at least for color transfer (I assume it is the same for autocontrast, 
but then, the code has changed a lot since I wrote it ;) ), the statistics is 
the mean and variance of the colors, so in a first pass, using the old 
pixels, you remove their value to the mean and sigma sums, and the one of the 
new pixels... outch but then that would change the transformation to the 
others pixels... rha, then the only solution is to do 1) as a preview, and 
run an update in a background thread like Boudewijn have suggested.

-- 
--- Cyrille Berger ---